Wikipedia:Village pump (technical): Difference between revisions

Policy

Technical

Proposals

Idea lab

WMF

Miscellaneous

• Table of contents
• First discussion
• End of page
• New post

Shortcuts

• WP:VPT
• WP:VP/T
• WP:TECHPUMP
• WP:PUMPTECH

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

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

view · edit Frequently asked questions (see also: Wikipedia:FAQ/Technical) Click "[show]" next to each point to see more details. If something looks wrong, purge the server's cache, then bypass your browser's cache. This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown. No, we will not use JavaScript to set focus on the search box. This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences. No, we will not add a spell-checker, or spell-checking bot. You can use a web browser such as Firefox, which has a spell checker. If you have problems making your fancy signature work, check Help:How to fix your signature. If you changed to another skin and cannot change back, use this link. Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem. If an image thumbnail is not showing, try purging its image description page. If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear. For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

This section is pinned and will not be automatically archived.

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

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

• No – my main reason for this stance is the over-all low quality of too many MusicBrainz pages linked from Wikipedia (examples can be given if needed – in the preparation to this RfC I asked if *anyone* could give me an example of a good, or at least decent, MusicBrainz page, which remained an "unanswered question"); Note that that previous argument is about the *actual* low quality of these pages, not merely about their WP:USERGENERATED status, which is of course a further argument; Further the BBC website does not seem to link to Wikipedia via MusicBrainz very often any more (only one example where they currently do could be given in the preliminary talks, after I had already given a counterexample); Further, the argument that Wikipedia should link to MusicBrainz mainly for its "authority control" characteristics does not outdo Wikipedia's policy against organising linkfarms (WP:NOTLINKFARM – keep links such as MusicBrainz in the Wikidata system where they can be accessed after one click from the Wikipedia article); The actual MusicBrainz identifiers are *longer* than what is displayed in the authority control box, respectively "artist/30060b66-4ed3-47a5-89d7-cb4f13437441", "artist/62c28bc0-f696-4c50-8e54-5f8e9120bdb8" and "release-group/18d4abd6-580d-45f1-8ba6-1d2bb1ad245f" for the examples given in the "Basics and technicalities" summary above: in other words the MusicBrainz system is not *actually* an Authority control system unless these longer names are used, and currently the MusicBrainz identifiers are already considerably longer than those of other identifiers in the authority control box; I would be open to any system that defaults to "no MusicBrainz" in the {{Authority control}} template and allows local override for those who checked the corresponding MusicBrainz page as being decent enough to link from Wikipedia. --Francis Schonken (talk) 08:43, 28 April 2020 (UTC)[reply]
  • 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)[reply]

    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)[reply]

    • Like I said: a basic misunderstanding of how the BBC use Musicbrainz; and a straw man. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:17, 9 May 2020 (UTC)[reply]
• No. The template should link to a small group of reliable, high quality, relevant, non-commercial, non-wiki databases. Even without things liks musicbrainz, it has way too many useless links (for enwiki readers) already, links from national libraries which are not in English and not in a language or country relevant for the subject, but which happen to be an authority control. Links which are added by default should be very, very limited. Wikidata is the perfect location to function as linkfarm for all these, from the truly authoritative to the near-junk ones (Quora?); enwiki should restrict this to much less than we have now, and excluding things like the wiki Musicbrainz is a good start. See for example Odilon Redon, French 19th century artist, not a musician by any stretch: there are 28 links already in the authority control template there, including musicbrainz. Such linkfarms don't help our readers one bit (e.g. [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)[reply]
• No, although referred to as an open encyclopedia, Musicbrainz has lots of user generated content and I don't think it is actually a reliable source. Also we're not a link farm → Lil-℧niquԐ1 - (Talk) - 10:01, 28 April 2020 (UTC)[reply]
• No – A lot is user-generated and therefore not a reliable source. —Ojorojo (talk) 13:41, 28 April 2020 (UTC)[reply]
• No, per all the rationale given above.--3family6 (Talk to me | See what I have done) 14:07, 28 April 2020 (UTC)[reply]
• No Low quality, user-generated "data" and completely circular (copies the Wikipedia article for the subject). It has no business being in an authority control any more than IMDb does, in fact less. Voceditenore (talk) 15:58, 28 April 2020 (UTC)[reply]
  • "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)[reply]
• Yes. Firstly, I'm very disappointed in the amount of misinformation that has been used in this discussion and the preceding preliminary discussion, so I'll start with a point-by-point rebuttal of all the arguments presented in the previous comments.
  • Francis doesn't give any examples of low quality pages; "quality" seems to be subjective and undefined in his comment. The two most sensible ways to measure quality in this context would probably be completeness and correctness; most similar databases cannot achieve the former to begin with, and MusicBrainz does not frequently contain errors (contrary to Francis's implication). For example, if you go to the page for an artist like The Carpenters, data exists for multiple releases of all their studio albums, as well as a large number of their compilation albums, with information for each track on each release and tracks on multiple releases being deduplicated where necessary (that is, they all have unique identifiers). The data is incomplete (since it does not contain all of their singles and does not contain the information about every release or the full credits of every single recording and composition), but it isn't wrong, and the latter is a more useful measure since it would be unreasonable to expect a music database to be complete.
    • I would also note that all the examples that Francis was actually able to give at Template talk:Authority control#MusicBrainz were invalid because they were apparently dependent on misunderstandings of the user interface. In my second reply to him there I responded to those examples.
  • Why is it relevant that the BBC doesn't link to Wikipedia via MusicBrainz? It's largely a red herring because it confers no reliability either way.
  • The length of the identifiers is completely irrelevant to their reliability and I'm surprised that it was even mentioned. {{Authority control}} usually takes up less area on the page than the infobox (even with dozens of identifiers) and is much less noticeable. If someone actually wanted to complain about the format of the links they had years to do it before this RfC.
  • The identifiers are unique both with and without the prefixes, because MusicBrainz assigns 128-bit UUIDs randomly and they are expected to be unique over any vaguely reasonable timeframe (collisions are not expected until about 10¹⁵ IDs have been generated). I don't know if the software actually handles collisions, but it should be unnecessary for some millions of years. Removing the prefixes in no way makes MusicBrainz less of an authority control (although there are certainly better reasons to argue that it isn't).
  • Manual checking for MusicBrainz links is not necessary, because the site has not been demonstrated to be uniquely unreliable among the websites linked to in {{Authority control}}.
  • MusicBrainz is one of many databases in the AC template and does not by itself usually make a significant difference to the number of identifiers, unless there are no or only a few other identifiers (in which case it's obviously not clutter). If {{Authority control}} needs to be downsized then that can be achieved with a much broader RfC; removing MusicBrainz – or any other individual database – would do basically nothing to address the issue. The links to national libraries are irrelevant to this discussion. (This appears to be Fram's only argument?)
  • The fact that MusicBrainz is not a reliable source is irrelevant to its inclusion in the template, even though some AC databases can be treated as reliable secondary or tertiary sources, because the template hosts external links and not sources. The template does not have any policy- or guideline-defined inclusion criteria that do not apply to any other templates; even if the links to MusicBrainz are removed from {{Authority control}}, the MusicBrainz-specific external link templates will still exist and will continue to be used.
  • The fact that MusicBrainz quotes Wikipedia articles (automatically, through a caching system based on MusicBrainz's links to Wikidata and Wikipedia) has no bearing on whether or not it should be used in the template. It is primarily for the convenience of MusicBrainz users, and it does not affect the site in a way meaningful to its inclusion in {{Authority control}}. Jc86035 (talk) 07:09, 29 April 2020 (UTC)[reply]
• (continued) Now that that's out of the way, this is why I would actually support the continued inclusion of MusicBrainz.
  • Firstly, there are no policies or guidelines which apply only to {{Authority control}}, which in terms of the applicable policies and guidelines can be treated primarily as an external link template. As such, since MusicBrainz external links will continue to be allowed regardless of the outcome of this RfC, there are no policy- or guideline-based reasons to disallow MusicBrainz links specifically.
  • MusicBrainz is sort of an oddball in the AC template, being the only website with user-generated content. However, this is not in and of itself a reason to remove it, because its inclusion can otherwise be justified, and the template does not have any guideline-defined inclusion criteria (other than those which were set by the previous RfC, which left the inclusion of MusicBrainz as an open question).
  • The purpose of {{Authority control}}, and AC in general, is to assign unique identifiers to entities. MusicBrainz generally accomplishes this, although this is obviously not unique to MusicBrainz. MusicBrainz identifiers, especially those for artists and works, are generally stable. In cases where there are duplicate entities, the older entity is usually the one retained. Additionally, artist identifiers are automatically removed after a week if they do not have any relationships to other entities, which means that they are always minimally identifiable; and MusicBrainz has a version control system which requires multiple users to agree for certain changes (including all destructive changes, such as merges and deletions).
    • 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)[reply]
• Yes. Per Jc86035 - Premeditated (talk) 15:49, 29 April 2020 (UTC)[reply]
• Yes - Jc86035 makes a lot of sense here. Thanks. Mike Peel (talk) 18:26, 29 April 2020 (UTC)[reply]
• No per Fram and Voceditenore. Nikkimaria (talk) 02:28, 1 May 2020 (UTC)[reply]
• Yes - per Jc86035. ‐‐1997kB (talk) 02:37, 2 May 2020 (UTC)[reply]
• No - in the ones I’ve seen, the link to MB has not generally offered worthwhile content. Sergecross73 msg me 03:34, 5 May 2020 (UTC)[reply]

  @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)[reply]

• 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)[reply]
• 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)[reply]

  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)[reply]

  Where did I say anything about not having trust in Wikidata? You attempt to put words into my mouth: don't. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:20, 9 May 2020 (UTC)[reply]

• Yes As an aggregate. And per Jc86035's extensive and careful analysis. Many of the arguments presented are red herrings since they apply to RS; this isn't meant to be a RS for content inclusion. Littleolive oil (talk) 17:20, 9 May 2020 (UTC)[reply]
• Yes, it’s an aggregate where people may well be searching, and has the unique identifiers that lead users to the right person, and so on. I concur that this isn’t a RS issue, it’s merely a locator. Montanabw^(talk) 19:05, 9 May 2020 (UTC)[reply]
• Yes for appropriate subjects, No for inappropriate ones. I just came across a MusicBrainz entry for Grafton, New South Wales, something called a "MusicBrainz area ID" (d:Property:P982 – just look at the examples there!). The material for Grafton found at MB is unsurprisingly poor; it's simply a poor mirror of Wikimedia data. The music-related material at MB is often poor, but it's also often the easiest available such link in many articles, so there is some value. To me, the most annoying thing about it is the huge number. Reducing that to something like "MusicBrainz: ...4059a" would lessen its visual pollution. -- Michael Bednarek (talk) 12:46, 14 May 2020 (UTC)[reply]

  @Michael Bednarek: The reason that places are in the database is to link them to artists and creative works, so most of the interesting data is actually in the other tabs and not the landing page; e.g. Grafton is linked to five artists who have lived or performed there. Jc86035 (talk) 16:21, 14 May 2020 (UTC)[reply]

  ... four of whom are thoroughly non-notable, and two of the three most famous singers from Grafton are not listed there. I think that's an indication of the generally poor quality of MB material. I've stricken my Yes above. -- Michael Bednarek (talk) 03:10, 15 May 2020 (UTC)[reply]

• Yes: MusicBrainz is very much in the spirit of Wiki(p|m)edia, and providing pointers to find more free/libre non-commercial content is a good thing. The external link policy should really be clarified to emphasize that. The situation's the opposite when it comes to non-free/non-libre/commercial services: Template:IMDb, Template:Google books, Template:Infobox_YouTube_personality, and similar are all grossly inappropriate corporate native-advertising spam, even if their creators are acting in good faith: those need swift and thorough eradication from the encyclopedia. —{{u|Goldenshimmer}} (they/them)｜Talk｜Contributions 22:51, 21 May 2020 (UTC)[reply]

• 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)[reply]

  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)[reply]

  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)[reply]

  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)[reply]

  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)[reply]

• 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)[reply]

  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)[reply]

  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)[reply]

  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)[reply]

  The inconvenience is that those watching this page for actually germane discussions will be distracted by an irrelevant one. --Bsherr (talk) 20:55, 4 May 2020 (UTC)[reply]

• Notifying the participants in the preliminary discussion who haven't commented yet: Nikkimaria, Tacsipacsi, Pigsonthewing. Jc86035 (talk) 08:14, 29 April 2020 (UTC)[reply]
• 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)[reply]

  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)[reply]

  @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)[reply]

  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)[reply]

  @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)[reply]

  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

  --Francis Schonken (talk) 11:29, 7 May 2020 (UTC)[reply]

  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)[reply]

• 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)[reply]

  @Nikkimaria: Yes, but then the burden of proof (per WP:NOCON) falls on those in favour of the change to demonstrate that a majority of the links are not appropriate. 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 artist pages would be acceptable. MusicBrainz provides unique, interlinked identifiers and other data/links, which means criterion 1 doesn't apply for most pages; even if the data is incorrect, criterion 2 doesn't necessarily apply because it's not 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)[reply]

  Jc86035, NOCON states "In disputes over external links, disputed links are removed unless and until there is a consensus to include them". ELNO would need to be assessed on a case-by-case basis; I don't agree with making blanket statements given the variety in page contents. For example, in the case of Jan van Eyck, the major content provided by the MusicBrainz link is a mirror of Wikipedia, which fails ELNO12. Nikkimaria (talk) 16:05, 9 May 2020 (UTC)[reply]

  @Nikkimaria: (I previously updated my comment to remove the mention of NOCON. Since you reverted it, it stays.) I would disagree with that assessment of the Jan van Eyck page – the reason that his entity exists in MusicBrainz is for the completeness of the release Deinós Nekrómantis, which the relationships tab on his item links to. (A slightly modified version of part of his work Crucifixion and Last Judgement diptych is used on the album cover, it seems.) That album doesn't have a Wikipedia article, so Wikipedia doesn't contain that information.

  This also doesn't make sense as a test to apply to authority control databases, because the reason we're linking to them (particularly the non-domain-specific ones) is for the identifiers, not the content. Even an individual VIAF entry could rarely be said to contain factual information not in a Wikipedia article aside from self-referential data. Jc86035 (talk) 16:16, 9 May 2020 (UTC)[reply]

  To your first point, that's a reason for the van Eyck page to exist on MusicBrainz; that is not a reason it meets EL on Jan van Eyck. We're not here to decide what should happen on the MusicBrainz site, but whether we should include that site in this external links template. We're also not here to discuss more broadly the value of the AC template in general, but whether this specific link warrants inclusion per our guidelines. Nikkimaria (talk) 16:24, 9 May 2020 (UTC)[reply]

  @Nikkimaria: ELNO12 can't apply to any individual MusicBrainz page; it only applies to the whole site (per "open wikis"), and for all intents and purposes MusicBrainz is established enough (although it's not really a wiki). Could you explain why you think ELNO1 applies to the page?

  • Is the relationship to the album insufficient?
  • Is the unique identifier insufficient?
  • Is it an issue with the cached Wikipedia content? What if it were not present? (The content is shown automatically, and removing it would necessitate the removal of both the Wikipedia and Wikidata links.)

  Jc86035 (talk) 16:31, 9 May 2020 (UTC)[reply]

  Specifically the second part of ELNO12: "Mirrors or forks of Wikipedia should not be linked". The van Eyck entry at MusicBrainz is primarily a mirror of the Wikipedia article. If the Wikipedia content were removed then ELNO12 would not apply, but the link still wouldn't warrant inclusion at Jan van Eyck per EL. Nikkimaria (talk) 16:35, 9 May 2020 (UTC)[reply]

  @Nikkimaria: Are you seriously suggesting that the entirety of MusicBrainz is primarily a Wikipedia mirror or that the item primarily exists for the purpose of being a Wikipedia mirror? It's not even a deliberate editorial choice, and it doesn't even show the entire article.

  Anyway, the reasons that authority control sites are linked to (which matter in this context and can't be dismissed just because the RfC is specific to MusicBrainz) would generally fulfill at least one of ELYES3, ELMAYBE3 and ELMAYBE4. (Additionally, the reasons listed in WP:EL seem to be written with the intent of being applied to pages with prose or media, and not databases, which might hinder their applicability.) Jc86035 (talk) 16:47, 9 May 2020 (UTC)[reply]

  No, I'm seriously suggesting that this particular entry is primarily a Wikipedia mirror. It doesn't particularly matter whether that's by editorial choice or automatic. If you'd like to go propose changes to EL that are tailored to databases go ahead, but as written MusicBrainz does not blanket-meet the criteria you outline. It might on particular articles, but what we're currently discussing is whether we should automatically include it on a wide range. Nikkimaria (talk) 16:56, 9 May 2020 (UTC)[reply]

  @Nikkimaria: ELNO12 only refers to sites as a whole, not individual pages. (In the interest of completeness: A mirror of Wikipedia is a site which has deliberately copied every article, which MusicBrainz hasn't done. MusicBrainz editors don't change the Wikipedia content after it's cached, so MusicBrainz isn't a fork of Wikipedia either.) Jc86035 (talk) 17:13, 9 May 2020 (UTC)[reply]

  ^{[citation needed]} Nikkimaria (talk) 17:14, 9 May 2020 (UTC)[reply]

  Referring to what? Jc86035 (talk) 17:20, 9 May 2020 (UTC)[reply]

  The claim that ELNO12 only refers to sites as a whole. Nikkimaria (talk) 17:25, 9 May 2020 (UTC)[reply]

  @Nikkimaria: ELNO states: "[…] one should generally avoid providing external links to: […] Open wikis, except those with a substantial history of stability and a substantial number of editors. Mirrors or forks of Wikipedia should not be linked." I'm not particularly familiar with the guideline, but my understanding of it is that the quoted text as written refers only to entire websites (since a single page would not be considered a mirror or a fork of Wikipedia). Only 4, 5, 8, 9, 11 and 16, I think, could be considered to refer to individual pages on third-party websites. Jc86035 (talk) 17:34, 9 May 2020 (UTC)[reply]

  The text you quote does not specify entire websites. It's quite possible to mirror a Wikipedia article on a single page of a site, and for that single page on the site to not be an appropriate external link on that article. Nikkimaria (talk) 19:10, 9 May 2020 (UTC)[reply]

• @Pigsonthewing: In the interest of clarity: I'm not entirely sure if it's appropriate to claim that WP:EL doesn't apply to {{Authority control}} at all, since it would mean that that one template would be in a class of its own separate from references and general external links. WP:EL is silent on the matter, and I don't know if there has been consensus on whether or not the guideline applies in this case. (Although, technically, linking to the Wikidata statements instead would resolve the issue entirely, since the template would link to Wikidata regardless through the pencil.) Jc86035 (talk) 17:34, 9 May 2020 (UTC)[reply]

See the third sentence at this section of the Germany article. Mobile Safari on my iPad is turning the year range, 919–1024, to a phone number. Putting nowiki tags around it does not solve it. Can this be fixed in the software? It is fine in other browsers. SandyGeorgia (Talk) 14:12, 29 June 2020 (UTC)[reply]

@SandyGeorgia: so, this appears to be an annoying "feature" of your browser and we probably won't do anything about it wide-spread in reading mode (in vediting mode, this was addressed in phab:T55315). So that leads us to either: (a) ignore this, (b) chose to inject hacks in to the text that will try to break this feature. (b) may have unintended side affects on other things, including indexing - so I'm not loving that idea. — xaosflux ^Talk 14:28, 29 June 2020 (UTC)[reply]

Didn't it get reported on this page three or four years ago, and wasn't it traced to a browser extension? --Redrose64 🌹 (talk) 22:14, 29 June 2020 (UTC)[reply]

@Xaosflux: This behaviour ought(?) to be addressable by adding <meta name="format-detection" content="telephone=no"> to the <head> of Wikipedia pages. I can't see any reason why we'd ever want automatic format detection of telephone numbers, so this ought not to pose an issue. meta format-detection is largely undocumented, and I'm only aware that it works in Safari and Microsoft Edge; that being said, it's a meta tag, so it doesn't do any harm besides a marginal impact on page size to have it in there. Naypta ☺ | ✉ talk page | 22:31, 29 June 2020 (UTC)[reply]

On writing this comment, I'd not seen the phab ticket you linked - I can now see this was considered. I'm not sure why it was decided we'd ever want automatic telephone number detection on any language Wikipedia, though. Naypta ☺ | ✉ talk page | 22:32, 29 June 2020 (UTC)[reply]

What happens if you type 919{{endash}}1024? Should render as 919–1024. Or use {{emdash}} if it's supposed to be an emdash, that's all over my head. Ivanvector (^Talk/_Edits) 22:35, 29 June 2020 (UTC)[reply]

@Ivanvector: To a browser just viewing the page contents as rendered by MediaWiki, 919{{endash}}1024 is identical to 919–1024. Using the template would only help with something that was parsing the wikitext, which the browser isn't doing here, because the MediaWiki software already parsed it on the server side. Naypta ☺ | ✉ talk page | 22:38, 29 June 2020 (UTC)[reply]

Ahh, I misunderstood the problem, I thought it was something to do with the editor. What if we created a template that would render the year range in a <span> that applied the relevant markup? (That's a bit over my head too, I last designed web pages when Geocities was still cutting-edge) Ivanvector (^Talk/_Edits) 22:45, 29 June 2020 (UTC)[reply]

@Ivanvector: That'd be doable, but it would require every instance of a date range–formatted like this to be changed to use that template. It seems to make more sense to me to just make the change sitewide using the meta tag, unless anyone can think of anywhere where such a highlighting functionality would be useful. Naypta ☺ | ✉ talk page | 22:48, 29 June 2020 (UTC)[reply]

This would need to be a configuration option and might even need to be done on a per-wiki bases for WMF, since I assume at least Wikivoyage if nowhere else allows phone numbers. I would guess that there are even some Wikipedias that allow/encourage phone numbers. Never mind 3rd parties. --Izno (talk) 23:31, 29 June 2020 (UTC)[reply]

@Izno: I'm surprised there isn't a page for interface admins to add arbitrary data to the <head> element of pages. Naypta ☺ | ✉ talk page | 09:08, 30 June 2020 (UTC)[reply]

IAdmins are a new user right for which this would be a novel use case, and it's not obvious to me if there are other, er, useful use cases that might tip the investment cost into worth doing. I'm not really sure of the utility of this change even, and I don't know if I would be in favor of opening other attack paths even for trusted users. --Izno (talk) 14:07, 30 June 2020 (UTC)[reply]

Naypta, i'm surprised that anyone would suggest that ppl without the highest of security clearance or at least subject to codereview before deploy, should be expected to be able to modify the head element of a top 10 website. —TheDJ (talk • contribs) 11:46, 1 July 2020 (UTC)[reply]

@TheDJ: without the highest of security clearance - interface admins already have the ability to completely break huge swathes of the site by changing pages in the MediaWiki namespace. They are our most trusted local technical users. For instance, changing sitewide CSS, JS, blacklisting potentially any website from edits, changing the "Create" and "Edit this page" texts, etc - and that's all on top of their standard administrative abilities, like editing the Main Page. Naypta ☺ | ✉ talk page | 11:52, 1 July 2020 (UTC)[reply]

Naypta, they are, but they also have access to a very specific piece of that head. In the head you can do 10000 things, including configuring of the sandbox in which that JS runs, modifying CSP, frame inclusion etc. We as developers have often said, that the only reason we have editors allowed to modify the JS is mostly historic. Had MediaWiki/Wikipedia been built after 2010 or so there is no way there would ever be sitewide scripts editable by the community in that way. —TheDJ (talk • contribs) 11:56, 1 July 2020 (UTC)[reply]

@Redrose64 and Naypta: this was discussed back in phab:T55315 - when it was interfering with visual editor; this appears to be a choice that the manufacturer of that specific browser has made (including not allowing their users to opt-out). Keep in mind, we are not asserting that this is a "phone number" or should be a link (such as by using the tel:// protocol link) - it is solely a client-side feature of that specific browser. No, we can't arbitrarily inject header elements from on-wiki, it would require a software change such as in T55315. We could break this case by injecting things like 0-width spaces in to the text, but that will cause worse problems. As far as the down side of asserting to not use this at all, readers that are currently using this to call actual numbers would have that functionality broken - not sure how many readers might use that? — xaosflux ^Talk 11:42, 30 June 2020 (UTC)[reply]

@Xaosflux: Personally, I can't think of any scenario in which a reader would actively want to click a telephone number off English Wikipedia - not least because we... wouldn't have them in the first place, I would have thought? Indeed, a brief and inexact regex check suggests that there are a very low number of US telephone numbers even on-wiki in the first instance, albeit that I'm only looking at US ones because otherwise it all gets a bit complicated. One supposes you might want it on for pages like List of suicide crisis lines, but I don't know how useful even that would be. Perhaps a magic word could be used to enable it for pages that really need it. Naypta ☺ | ✉ talk page | 11:59, 30 June 2020 (UTC)[reply]

Adding a meta value to the header, or creation of magic words can not be done on-wiki, you would need to request a software change. — xaosflux ^Talk 12:37, 30 June 2020 (UTC)[reply]

Xaosflux, readers that are currently using this to call actual numbers would have that functionality broken: I think it's more niche to legitimately have phone numbers on Wikipedia that users might want to call. In which case, we can use the header tag and still make it possible to click the links by wrapping them in <a href="tel:1-408-555-5555">1-408-555-5555</a> [2]. We can create a template to make it a bit neater. I think this would seem like an ideal solution? ProcrastinatingReader (talk) 13:16, 30 June 2020 (UTC)[reply]

It sounds worthy of reviewing with the devs, feel free to open a feature request on phab. Of course, someone could argue this to that browser maker too. — xaosflux ^Talk 13:22, 30 June 2020 (UTC)[reply]

Created T256758. Apple has a long list of user complaints and requests re. Safari and WebKit - I have a feeling they won't be too responsive to fixing this one (anytime soon) :/ ProcrastinatingReader (talk) 13:35, 30 June 2020 (UTC)[reply]

Created 213836 in WebKit's Bugzilla as well. ProcrastinatingReader (talk) 13:40, 1 July 2020 (UTC)[reply]

"Personally, I can't think of any scenario in which a reader would actively want to click a telephone number off English Wikipedia - not least because we... wouldn't have them in the first place" there's a telephone number, legitimatey, on Wikipedia:Contact us/Press and partnerships, for example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:11, 9 July 2020 (UTC)[reply]

@Pigsonthewing: Sure, but so in those edge cases, we can manually link using [tel:blah blah], surely? Naypta ☺ | ✉ talk page | 16:13, 9 July 2020 (UTC)[reply]

@Naypta: Firstly, can you confirm that the proposed fix does not also override such markup? Secondly, please provide a working example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:38, 9 July 2020 (UTC)[reply]

@Pigsonthewing: Certainly; here's an example of the link on Press and partnerships as a tel: link. I can confirm that this works with format-detection set in meta to false; the only thing the format-detection tag does is enable or disable the detection process. It certainly wouldn't be able to affect existing protocol links on a page. Naypta ☺ | ✉ talk page | 16:42, 9 July 2020 (UTC)[reply]

I found them, but had to go back much further than I imagined: Wikipedia:Village pump (technical)/Archive 70#Unusual undo results?; Wikipedia:Village pump (technical)/Archive 71#Bizarre interaction with Skype; Wikipedia:Village pump (technical)/Archive 90#Skype problem - processesing "invisible" text; and Wikipedia:Village pump (technical)/Archive 91#How to remove Skype formatting when it shows up?. --Redrose64 🌹 (talk) 14:39, 30 June 2020 (UTC)[reply]

This particular case seems to just be Apple being Apple, rather than a Skype extension, unfortunately. I confirmed on my phone which doesn't have the Skype extension. If you have an iDevice you can likely confirm by viewing User:ProcrastinatingReader/sandbox on iOS (probably iPadOS too) Safari. Doesn't happen on macOS Safari. ProcrastinatingReader (talk) 14:43, 30 June 2020 (UTC)[reply]

@SandyGeorgia: does this work: {{as written|919–1|024}} = 919–1024? Mathglot (talk) 18:58, 4 July 2020 (UTC)[reply]

@Mathglot: still a phone. SandyGeorgia (Talk) 20:11, 4 July 2020 (UTC)[reply]

@Mathglot: I wouldn't expect it to work, because the problem that Sandy is experiencing is client-side, their browser acts on the HTML that is served, not on the Wikitext. --Redrose64 🌹 (talk) 08:27, 5 July 2020 (UTC)[reply]

Here is a new twist, at Ajpolino‘s work on Buruli ulcer, epidemiology section. 2000–5000 is also converting to a phone number (I will write it out instead, removing the endash). If we write it incorrectly, with a hyphen instead of endash, 2000-5000, does same. SandyGeorgia (Talk) 13:18, 6 July 2020 (UTC)[reply]

Your current software is broken. Free alternatives are available. Why are you still using it? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:13, 9 July 2020 (UTC)[reply]

On some platforms, such as iOS, there are no alternative rendering engines available (all third-party browsers are essentially skins on WebKit). --Ahecht (TALK
PAGE) 16:48, 9 July 2020 (UTC)[reply]

From the OP:: "Mobile Safari on my iPad". Here is a link to download Mozilla Firefox for iPad. Firefox does not use WebKit. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:32, 9 July 2020 (UTC)[reply]

@Pigsonthewing: Firefox for iOS does use WebKit: It is the first Firefox-branded browser not to use the Gecko layout engine as is used in Firefox for desktop and mobile. Apple's policies require all iOS apps that browse the web to use the built-in WebKit rendering framework and WebKit JavaScript, so using Gecko is not possible. --Ahecht (TALK
PAGE) 18:33, 9 July 2020 (UTC)[reply]

I stand corrected; the device is broken, not the browser. Another reason to void Apple products. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:28, 9 July 2020 (UTC)[reply]

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following list: Wikipedia technical issues and templates When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

Should a <meta> tag be added to all Wikipedia pages to prevent supporting browsers (IE, Edge, Safari) from automatically converting telephone number-like formats to tel: links? Naypta ☺ | ✉ talk page | 11:19, 1 July 2020 (UTC)[reply]

• Support as proposer. For the context of this proposal, see above, and also phab:T256758. For a brief summary: this behaviour is causing number ranges like 919–1024 to be turned into clickable links, as if [tel:919–1024 919–1024] had been written, on newer versions of Internet Explorer, Microsoft Edge and Safari. This behaviour is called format detection, and is designed to help the user easily contact telephone numbers; however, users would never normally be calling telephone numbers off of enwiki, and we have a low number of them in the first instance. Inserting <meta name="format-detection" content="telephone=no"> into the <head> element of Wikipedia pages would prevent this behaviour, without adding a great deal of overhead to our pages; we have a number of similar tags in the <head> at present. Naypta ☺ | ✉ talk page | 11:19, 1 July 2020 (UTC)[reply]
• Comment: I don’t know enough of the issues involved to feel qualified to enter an opinion, but thanks to all for attempting to resolve this. SandyGeorgia (Talk) 12:04, 1 July 2020 (UTC)[reply]
• Your search only attempts to identify a limited set of phone numbers. See National conventions for writing telephone numbers. --Izno (talk) 13:43, 1 July 2020 (UTC)[reply]

  I observed this above; it all gets a bit complicated when you try and find formats for other telephone numbers. Ironically, that's the very same reason this issue exists in the first instance; it's almost impossible to define an accurate pattern match that encompasses all international telephone numbers, or even a majority of them. Naypta ☺ | ✉ talk page | 13:47, 1 July 2020 (UTC)[reply]

• I oppose. A limited use set of browsers have undesirable behavior. Bugs should be filed against those browsers. Users are also free to select another browser to correct the issue. --Izno (talk) 13:44, 1 July 2020 (UTC)[reply]

  I'm not sure the issue here is actually a bug per se with the browsers; rather, the browsers are doing what they're meant to here, it's just that what they're meant to do isn't useful for Wikipedia. Naypta ☺ | ✉ talk page | 13:47, 1 July 2020 (UTC)[reply]

  If the design is bad then Broken As Designed (BAD) is a bug. That limited set of browsers covers a large chunk of users. BTW, I would find that defect even more obtrusive for content outside of wiki.Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:05, 1 July 2020 (UTC)[reply]

  Seems to be a browser issue that should be fixed there - especially since this browser is doing this on numbers with en-dashes in them, not just hyphens as traditionally used for this style of phone number. — xaosflux ^Talk 16:23, 1 July 2020 (UTC)[reply]

  It may be that "what they're meant to do isn't useful for Wikipedia", but browsers answer to their users, not to Wikipedia. Put another way: if Safari decides to render all its text upside down, that would not be useful to Wikipedia, but if Safari users like it, then its not our business to interfere. Mathglot (talk) 19:31, 4 July 2020 (UTC)[reply]

  @Mathglot: Browsers answer to their users, and we answer to ours. If we have a way of overriding browser functionality, where it's helpful to our users so to do, I am minded to think that we should take advantage of that, irrespective of the decisions that a browser manufacturer may or may not make. Naypta ☺ | ✉ talk page | 20:15, 4 July 2020 (UTC)[reply]

  @Mathglot: if Safari decides to render all its text upside down, would you then argue that we should invert our text, so it looks right in Safari? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:21, 9 July 2020 (UTC)[reply]

• Oppose working around this apparent browser bug/misfeature, especially since the ability to click phone numbers may be useful for some readers and the proposer shows no evidence of investigating whether that feature is useful to some en.WP readers. – Jonesey95 (talk) 16:28, 1 July 2020 (UTC)[reply]

  @Jonesey95: the proposer shows no evidence of investigating whether that feature is useful to some en.WP readers - we do not, for the most part, have telephone numbers on the English Wikipedia; it is antithetical to our nature as an encyclopedia, for the most part, so to do. We are, after all, not a directory. I explained above the difficulty in programmatically identifying usages of telephone numbers thanks to their varied formats, but I did run a search for US format numbers, which you can find in the original proposal. Furthermore, pages would still be able to manually add tel: links, where exceptions did apply for whatever reason; we're only talking here about disabling automatically adding links, where there's no special markup present. Naypta ☺ | ✉ talk page | 23:05, 4 July 2020 (UTC)[reply]

• Why is this here, and not at WP:VPR? --Redrose64 🌹 (talk) 20:50, 1 July 2020 (UTC)[reply]

  @Redrose64: Because it's a technical discussion that I doubt would be of interest to the majority of people at WP:VPR - discussing the nature of specific meta tags on wiki pages isn't exactly a riveting conversation among techies, never mind among people without technical experience. Please feel free to post a message over there as well though if you think it's apt so to do! Naypta ☺ | ✉ talk page | 20:54, 1 July 2020 (UTC)[reply]

  The effect is not a technical issue, though. I think a broader audience would be desirable. isaacl (talk) 18:27, 5 July 2020 (UTC)[reply]

• Support, with the proviso that there be a template to specify that a number is a telephone number. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:33, 1 July 2020 (UTC)[reply]
• Oppose – Wikipedia should not get into the business of trying to undo or override what browser designers believe are useful features for their users. Who's to say Safari designers won't recognize the <meta> tag, and make a change to undo its effect, and turn it into a phone number anyway, thus fixing Wikipedia's "fix"? Where does it all end? Is this the start of a new Wikipedia:Browser override features policy page? Mathglot (talk) 19:16, 4 July 2020 (UTC)[reply]

  For mobile Safari, the format-detection meta tag is the documented way to turn off telephone number detection provided by Apple for sites who wish to disable the functionality. isaacl (talk) 18:27, 5 July 2020 (UTC)[reply]

  What isaacl said, the whole point of the meta tag is to turn off automatic detection (and require it manually). It's a feature of browsers. I don't see why they would ignore the presence of a tag per a feature they themselves created to allow sites to opt-out. ProcrastinatingReader (talk) 12:56, 6 July 2020 (UTC)[reply]

  It's not a fetaure of the web (HTML) standards, which include an agreed method for marking up telephone numbers. Go and tell the browser maker to follow the standards, or at least to lobby to change them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:16, 9 July 2020 (UTC)[reply]

• Support I don't see any harm in doing so, and in addition to blocking mis-identified phone numbers, it could help reduce spam from people trying to insert their phone numbers into articles and drafts (since the numbers would no longer be clickable, it would be less attractive to do so). --Ahecht (TALK
  PAGE) 23:32, 6 July 2020 (UTC)[reply]
• Comment I would like to support this proposal, but first since we are a top-10 website, someone official should have a tête-a-tête with Apple developers regarding Safari's behavior. Is this the best way to solve this? Is it a standards-based way to solve it? Is there a movement toward standardization of this? At any rate, I think if we added this as a stopgap now and it works, then we can move the conversation forward about standardization. Elizium23 (talk) 23:45, 6 July 2020 (UTC)[reply]
• Comment does anyone know if adding a Zero Width Non-Breaking Space (U+FEFF) or Word Joiner (U+2060) would disrupt this behavior? VanIsaac_WS^cont 20:57, 7 July 2020 (UTC)[reply]
• Oppose It's not our job to work-around this kind of browser bug. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:11, 9 July 2020 (UTC)[reply]
• Support - this is a simple solution to an external issue causing accessibility issues for our readers, which means it is our problem. The fix won't impact users of other browsers at all, so why not? Ivanvector (^Talk/_Edits) 16:46, 9 July 2020 (UTC)[reply]

I want to find everybody who has ever been an admin, when they (possibly more than once) got the bit. And, for some, when they lost it. My first thought was some kind of database query. This, for example, is my RfA, but there's not enough information in the log to determine that. I found that record by looking up my RfA, and using that to narrow down the log_timestamp range. Is that just because in the old days, logging didn't happen the way it does now? Do I need to resort to finding all the subpages of WP:RfA and parsing them? -- RoySmith (talk) 20:06, 5 July 2020 (UTC)[reply]

RoySmith, parsing RfA subpages is a probably necessary when "log_params" is empty as there is no data (as you say) which helps identify the user group change. I have some ideas which would help but not account for all cases where the sysop flag was granted or removed:

• Perhaps a query could take into account the log comment of the user group change. For example when you had your sysop flag given the log comment was "+sysop". This can be done in a query via inner join (like this) on the comment table. Filtering for user group changes with -sysop or +sysop (or variants) would give you presumably a large proportion of pre-"log_params" user group changes where the sysop flag was removed or granted. It wouldn't catch user group changes which were not descriptively marked, but sysop user group changes seem like the kind of thing which would be properly marked.
• Possibly a script could filter user group changes based on first administrative action. My thinking here is that an administrator could not make a action which required the sysop flag without first being an administrator. This would mean that you could safely say the granting of their administrator flag was before their first administrative action. This would probably only easily work for logged actions. I can't think of any way to filter for removal of the sysop flag using this method.

These two ideas would likely filter down your pool of RfA subpages to parse and/or user group changes to investigate. Removal of sysop rights without using the first idea seems a bit more difficult, as I am unsure of anywhere which logged -sysop right changes (like RfA does for +sysop). Dreamy Jazz ^{talk to me | my contributions} 21:32, 5 July 2020 (UTC)[reply]

• Try something like this: https://quarry.wmflabs.org/query/46364 ProcrastinatingReader (talk) 12:52, 6 July 2020 (UTC)[reply]

@RoySmith: Perhaps you might do something with WP:LA's revision history if the database queries don't work out? Naypta ☺ | ✉ talk page | 13:09, 6 July 2020 (UTC)[reply]

• One of the truisms about any big data project is that the data is always messy. This seems to be no exception :-). I tried ProcrastinatingReader's query, which looks good (thanks!), but the earliest it comes up with is Duk in December 2004. Poking around a bit, I found Wikipedia:Successful requests for adminship and even better, User:NoSeptember's User:NoSeptember/RfA chronological, which looks like the definitive record of the early days (horray for historians!). So, I'm thinking some combination of log queries for anything from about 2005 on, and fill in the early history with page parsing and/or manual augmentation. I'm not sure what I'm going to do about desysopings, but for my purposes, finding the first and last logged admin action for each user is probably good enough. -- RoySmith (talk) 13:22, 6 July 2020 (UTC)[reply]
• I'm assuming you're looking to compile a single database inclusive of all that information. However, Former administrators contains a ton of information, and otherwise List of administrators contains much of the info, but in separate lists. — Maile (talk) 13:36, 6 July 2020 (UTC)[reply]
• The older logs of removing admin bits are on meta, not en.wp, as the stewards used to remove the bit, before beurocrats did. See for example [3].--Snaevar (talk) 17:05, 6 July 2020 (UTC)[reply]

  Crats were granted the ability to desysop as a result of this RfC which concluded in August 2011. --Redrose64 🌹 (talk) 11:47, 7 July 2020 (UTC)[reply]

• For most of 2004 there's the old bureaucrat log. Graham87 11:18, 7 July 2020 (UTC)[reply]

Is there any way for a user script to find out when the user previously viewed the current page? — GhostInTheMachine ^{talk to me} 13:42, 6 July 2020 (UTC)[reply]

I don't know if such a script exists, but if it did, it would raise serious questions about the purpose of it. Who are we, if we can track any user by what pages they happen to click on, and how many times? — Maile (talk) 14:40, 6 July 2020 (UTC)[reply]

I think GhostInTheMachine may mean tracking himself, i.e. seeing (on their next visit) when they last viewed the page. ProcrastinatingReader (talk) 15:11, 6 July 2020 (UTC)[reply]

ProcrastinatingReader, As I'm sure you're aware, if you're using Chrome, Google is tracking what you do. You can see what they've got on you at https://myactivity.google.com/. You might be shocked to discover just how much they know about you, but they might also have the data you seek. Your local browser history might have something as well. -- RoySmith (talk) 15:16, 6 July 2020 (UTC)[reply]

ProcrastinatingReader, I understood perfectly that he was talking about his own clicking history. I'm just saying that if Wikipedia has such a tool, it could also be used to check the browsing history of other viewers. — Maile (talk) 15:20, 6 July 2020 (UTC)[reply]

It doesn't have to be part of MediaWiki. Since he's talking about a script, it could just be something that logs each page you visit and saves it into a database with a timestamp. ProcrastinatingReader (talk) 15:40, 6 July 2020 (UTC)[reply]

Ah, yes, I see that now by the above mention of browser history. Thanks. — Maile (talk) 15:42, 6 July 2020 (UTC)[reply]

Watchlists aren't visible to others, surely then it should be possible to create something for "my last visits" that is also private? DuncanHill (talk) 20:09, 6 July 2020 (UTC)[reply]

I am writing a user script — which loads from Wikipedia for me and runs in my browser. The script currently does have all sorts of interesting data available to it — about my account: my username, how many edits I have done etc. — about the page: the pagename, the version id of the page, which categories it belongs to etc. However, I have not been able to find if/what data is available about me vs the page: Have I edited this page? Is this page in my watchlist? When did I previously visit this page? Since the script has no access to the browser history and I could be on a different device, can anybody think of how I could get hold of when was my previous visit? — GhostInTheMachine ^{talk to me} 16:55, 10 July 2020 (UTC)[reply]

Is there a way to stop all blocked users from emailing me? If a user is blocked, it's unlikely they have a need to contact me- just received one which was just a rant from blocked user that they shouldn't be blocked. Whilst I can just delete them, it'd be better if I can just policy block these emails. Joseph2302 (talk) 21:07, 6 July 2020 (UTC)[reply]

Removing your e-mail adress from your Wikipedia account, I guess.Tvx1 21:10, 6 July 2020 (UTC)[reply]

The above reminds me of a bot that I am working on that deletes 100% of all Wikipedia vandalism and spam and never misses any. It is almost finished; I just have to fix one small bug (it deletes everything else along with the spam and vandalism) but I should be able to fix that last minor bug in the next couple of days and we will be good to go. --Guy Macon (talk) 22:53, 6 July 2020 (UTC)[reply]

As part of the block, administrators can remove email access. I'm not sure where the best place is to request that addition to those blocks. --Izno (talk) 23:32, 6 July 2020 (UTC)[reply]

Joseph2302, If it's just annoying, I'd say report it to the admin who blocked the user, or if you can't get in touch with them, any admin should be fine. They can adjust the user's block to not allow them to send mail. You could post a request at WP:ANI, or if you prefer not to make your request in public, email any admin by clicking the "Email this user" link in the nav bar on their user page.

Please don't feel like you're imposing on an admin by requesting they deal with this. That's what admins are there for.

If the problem has gone past annoying, take a look at Wikipedia:Harassment#Dealing_with_harassment for additional things you might do. -- RoySmith (talk) 01:24, 7 July 2020 (UTC)[reply]

@Joseph2302: I've opened a feature request for you at: phab:T257514. — xaosflux ^Talk 20:01, 8 July 2020 (UTC)[reply]

I wonder if there is a better way to solve this than by giving everyone a new preference option that is hard to discover, in the already very bloated preferences tab. Should blocked users be allowed to not email anyone except admins (to appeal blocks)? Is there a need for blocked users to contact other users? -- NKohli (WMF) (talk) 03:33, 9 July 2020 (UTC)[reply]

Everything is complex when thousands of users are involved. I have seen a couple of cases where it was desirable for a blocked user to email a non-admin editor (me, when I was a non-admin). In one case, I was asked to look at the background to the block and I called for a review at WP:AN where it was agreed the admin was wrong and the block was overturned (the admin ended up desysoped after another incident, as I recall). Then there was a self-requested block where the person wanted to discuss something...I forget what, but I replied. The request here is very short on details but it looks like there was a single incident from one blocked user and that doesn't seem to justify anything more than removing email from the blocked account. Johnuniq (talk) 04:44, 9 July 2020 (UTC)[reply]

NKohli (WMF), there are many wikis with no local admins, which might be a consideration.

Another thing to consider: most blocks are local, so if an experienced editor were blocked here and thereby prevented from e-mailing me (I have no advanced rights anywhere), they'd probably just go to another SUL wiki and send the e-mail message from there. Whatamidoing (WMF) (talk) 20:58, 9 July 2020 (UTC)[reply]

I have a script which added ReFill and ReFill 2 to my toolbar for easy access. ReFill 2 is pulling back a 404 error... GiantSnowman 11:27, 7 July 2020 (UTC)[reply]

• I'm thinking this might be related to the fact that ReFill has now migrated from Wmflabs to Toolforge. Even ReFill's interface looks slightly different than it did 24–48 hours ago. Steel1943 (talk) 17:42, 7 July 2020 (UTC)[reply]

Is there a fix for this? GiantSnowman 14:15, 8 July 2020 (UTC)[reply]

GiantSnowman: Per the conversation at T257471, I just had success via https://refill.toolforge.org/. = paul2520 (talk) 02:55, 9 July 2020 (UTC)[reply]

@Paul2520: the tool script has also been fixed, huzzah! GiantSnowman 09:42, 9 July 2020 (UTC)[reply]

Hello, I'm still getting a 404-Not Found message...although reFill appears to be working for some users? Thanks. Caro7200 (talk) 16:39, 9 July 2020 (UTC)[reply]

Yep, getting a 404 error here too. Steel1943 (talk) 17:16, 9 July 2020 (UTC)[reply]

Steel1943 and Caro7200 please see this thread below Wikipedia:Village pump (technical)#Further expertise to getting bare urls tool working. Things are working again for me and I hope the same applies to you. MarnetteD|Talk 21:11, 9 July 2020 (UTC)[reply]

ReFill has not been working all day (Saturday July 11). All I get is a 404 . ThatMontrealIP (talk) 04:07, 12 July 2020 (UTC)[reply]

I see, from the link in the section below (perhaps the two sections should be merged?) the variant link does work. Thanks. ThatMontrealIP (talk) 04:10, 12 July 2020 (UTC)[reply]

The WMF developers rolled out a configuration change this morning (or was it last night?) which changed how user tools get called. Apparently, this broke a few tools (ReFill 2 looks like one of them, based on the above section). I can't blame this on WMF; they gave people advance notice, but change is change, and things break. See wikitech for more background. So, if some tool you've been using has suddenly broken today (not Thursday!), that's a good first guess why. -- RoySmith (talk) 17:54, 7 July 2020 (UTC)[reply]

For those cases where an interwiki prefix is used, see also meta:Talk:Interwiki_map#Update_target_URL_for_'toolforge'_and_'toollabs'_IW_prefixes.--Snaevar (talk) 20:57, 7 July 2020 (UTC)[reply]

This may be why GeoHack is currently broken (for me, at least). Clicking on the geographic coordinates in any WP article that contains a {{coord}} template leads to a "308 Permanent Redirect" error page. Seems pretty significant when it's not just a editing tool like ReFill 2 but an integral part of our public-facing functionality. Deor (talk) 22:45, 7 July 2020 (UTC)[reply]

Another reason why GeoHack should not be an integral part of our public-facing functionality. We should replace it with Kartographer, which is maintained by the WMF. Kaldari (talk) 13:55, 8 July 2020 (UTC)[reply]

This answers a question I came here to ask. As of this morning, the bookmarked URL I use to get my own AFD stats from Toolforge didn't work. It returns the message "404 - Not Found". I can get the stats by manually inserting the URL for afdstats.toolforge.org, and then fill out the template that pops up. Every time. The URL that pulls up as a result, is the exact URL I had book marked. And today, I have to manually input it every time during the day I want to check my AFD stats. — Maile (talk) 23:38, 8 July 2020 (UTC)[reply]

Oh, yeah, there's another thing that hasn't been working today. Assume this is related. The "autofill" feature in the drop-down RefToolbar in the edit screen. — Maile (talk) 00:26, 9 July 2020 (UTC)[reply]

@Maile66: Someone with editinterface permissions needs to change "var url = '//tools.wmflabs.org/reftoolbar/lookup.php?';" to "var url = '//reftoolbar.toolforge.org/lookup.php?';" at MediaWiki:RefToolbar.js. Kaldari (talk) 13:33, 9 July 2020 (UTC)[reply]

I bet xaosflux can help! Kaldari (talk) 15:08, 9 July 2020 (UTC)[reply]

RefToolbar.js has been updated to the new URL, if anyone runs across others of these in need of fixing, please drop an edit request on the associated talk page. — xaosflux ^Talk 16:04, 9 July 2020 (UTC)[reply]

@Maile66: What link are you using? Something like toolforge:afdstats/afdstats.py?name=ahecht&max=500&startdate=20150101&altname= works fine for me. --Ahecht (TALK
PAGE) 15:55, 9 July 2020 (UTC)[reply]

@Ahecht: Well, yeah. As of this exact posting here, it works just fine for me - same bookmark link as I had before. A couple of minutes ago, it didn't. Hmmmph. Maybe it got fixed now. — Maile (talk) 16:04, 9 July 2020 (UTC)[reply]

Hi folks,

VRTS ticket # 2020070710009213 has raised that Normal distribution seems to cause a significant CPU spike in Chromium. Testing in -tech on IRC has suggested the issue can be replicated with other chromium-based browsers (Chrome, Edge), but not in Firefox. The issue may be caused by the high volume of math markup on that page. I've logged a Chrome bug ticket on their suggestion, but wondering if we are able to further root cause the issue? Best, Darren-M talk 19:26, 7 July 2020 (UTC)[reply]

@Darren-M: Is there a link to that "Chrome bug ticket", please? --Malyacko (talk) 10:17, 9 July 2020 (UTC)[reply]

I can replicate this on my machine with Chrome 83.0.4103.116 and 64-bit Windows 10. Least squares has a similar effect; my CPU usage jumps from less than 10% to 20-40% as soon as I load either of those pages. As soon as I leave the pages and load any other article (or other web page), it returns to normal. Home Lander (talk) 21:11, 9 July 2020 (UTC)[reply]

When I go to a Wikipedia page for a Commons file, say File:Akha couple.JPG, it is missing the download button that appears in the box just below the title when the same image is viewed at Commons. For images, it's not overly hard to download them by clicking on the image and then right clicking it, although I could see some more technology-averse readers getting tripped up by it. But for audio files, readers are very likely to get tripped up, since File:Black.ogg provides nowhere to download, and most readers won't know to click the "View on Commons" button. Could we get the box from Commons with the download button/other options appearing here, too? {{u|Sdkb}} ^talk 04:17, 8 July 2020 (UTC)[reply]

@Sdkb: I don't think anything is "missing", in that that is not supposed to actually be there. I think you are referring to a gadget that commons has, commons:Help:Gadget-Stockphoto? — xaosflux ^Talk 18:09, 8 July 2020 (UTC)[reply]

Yeah, I think that's the box. There are a ton of usability issues with how files are presented, but I won't wade into that since I know there's a whole history with MediaViewer and all. For my application, I just used an interwiki link to Commons as a workaround. But I just wish that the design of those pages took into better consideration the basic uses readers are likely to desire from file pages. {{u|Sdkb}} ^talk 05:15, 9 July 2020 (UTC)[reply]

Is there any way to automatically fetch the duration and file size of an audio file hosted at Commons? I'm redesigning {{Spoken Wikipedia}}, and I'd like a way to display that information automatically. For instance, for duration I'd like a template that'd take "File:Black.ogg" as input and return "10:10". I tried {{Template parameter value|File:Black.ogg|English spoken article||time}} as an extreme Hail Mary, but it didn't work. {{u|Sdkb}} ^talk 05:38, 8 July 2020 (UTC)[reply]

@Sdkb: We can't even fetch the dimension of an image file, so I don't see this becoming a possibility anytime soon. Durations are rather stable (provided c:COM:OVERWRITE is followed), so manual insertion of static values shouldn't pose much of a problem, I suspect. Nardog (talk) 09:50, 9 July 2020 (UTC)[reply]

File size is gotten in the (Lua) Module namespace with "mw.title.new("Black.ogg", "File").file.size". It was added in phab:T54522. File duration of audio files however was overlooked, so please file a bug for that on phabricator, with "MediaWiki-extensions-Scribunto" in the tag field.--Snaevar (talk) 12:50, 9 July 2020 (UTC)[reply]

@Nardog and Snaevar: Interesting, I didn't know about that. I tried it in Module:Sandbox/Johnuniq/temp (permalink) with the results displayed here. The code is showing the original width and height of this image. Johnuniq (talk) 02:16, 10 July 2020 (UTC)[reply]

Thanks all! Snaevar, I've created the task at T257650. I'm not skilled enough at Lua to know how to use it once implemented, but I'll ask if it gets to that point (the end goal is being able to include the duration/size on {{Spoken Wikipedia}} without the adding editor having to enter it manually). {{u|Sdkb}} ^talk 05:31, 10 July 2020 (UTC)[reply]

Searching for insource:/last3=Ist\|/ finds roughly 1630 articles/pages with weird garbage in authors and titles. Mostly on India-related pages. For example

• 2008 Kandhamal violence had this sort of garbage in the authors/title

Asking help to track

• 1) The cause of this (VE, Citoid, RefToolBar, Citation bot?)
• 2) The fix to whatever caused this
• 3) Help cleaning up the garbage (probably bot-assisted). Even just removing all the crap in the authors/title without adding the correct authors/date would be a huge improvement.
• 4) Does this affect more than just India-related articles?

Headbomb {t · c · p · b} 15:55, 8 July 2020 (UTC)[reply]

After digging, it seems related to the VisualEditor [4]. Headbomb {t · c · p · b} 16:15, 8 July 2020 (UTC)[reply]

The source in [5] is [6] which says "M T Saju | TNN | Updated: Feb 16, 2017, 08:50 IST". The citation was copied from [7] in another article, made with mw:Citoid in VisualEditor trying to automatically find author names. IST means Indian Standard Time so a search on "IST" will give many India-related articles with this particular wrong author. PrimeHunter (talk) 16:58, 8 July 2020 (UTC)[reply]

The way that Citoid makes references from web resources is that it first checks to see if a Zotero translator exists for a website. If not, it will guess based on the semantics in the HTML of the page source who/what is the right way to translate a webpage into a reference. The 'easiest' way to 'correct' this is to write a Zotero translator. --Izno (talk) 17:35, 8 July 2020 (UTC)[reply]

Izno, I suspect you're right about this being a Zotero-ism, but I want to mention another possible way weird stuff gets into citations and/or quotes. Some web sites add "watermarks" when you copy-paste text from their site. I've seen this on lyrics sites, and some newspapers. If you're not actually paying attention to what you're doing, these watermarks get into your wiki text. So, if you ever see something like "from my totally awesome lyrics site" in the middle of some text, that's probably why. -- RoySmith (talk) 17:52, 8 July 2020 (UTC)[reply]

Or ditch obviously non-functioning tools like Citoid.

Or block all editors who do not care for their editing and repeatedly save such a crap. At least a minimum of competence is required.

--Matthiaspaul (talk) 17:56, 8 July 2020 (UTC)[reply]

Headbomb, are you seeing recent edits (April 2020 or later) with this garbage in them? The phabricator task linked above indicates that at least some of this should have been patched in March 2020. If we have newer examples of garbage edits via Citoid, examples should be added to that task. If there are no recent edits, we just need to fix a couple thousand articles. (edited to add: Never mind, I found two examples and added them to the ticket.) – Jonesey95 (talk) 17:59, 8 July 2020 (UTC)[reply]

Matthiaspaul, I think you're hating on Citoid excessively. I think it's awesome. Could it be better? Certainly. But it's a heck of a lot better than formatting references by hand. -- RoySmith (talk) 18:01, 8 July 2020 (UTC)[reply]

I suspect that writing (or updating) Zotero translators for commonly used reliable sources would be eligible for grant funding under m:Grants:Project/Rapid. I don't know how "rapid" the rapid grants are right now, but maybe someone here will know someone who is available and might be interested. Whatamidoing (WMF) (talk) 21:12, 9 July 2020 (UTC)[reply]

In these two edits, I added an image to COVID-19 pandemic in New York City. The image caption is showing as link=File:NYC_Bus_with_%22masks_required%22_sign.jpg. If I look at it in the Visual Editor, it seems fine. Any idea what's going on? See screenshots at right. -- RoySmith (talk) 18:26, 8 July 2020 (UTC)[reply]

There are a lot of little bugs in image syntax. Someone needs to review the spec and the implementation with an detail-oriented eye. I have added this apparent bug report to the existing T216003, and I added this issue to mw:Help:Images. – Jonesey95 (talk) 18:44, 8 July 2020 (UTC)[reply]

There is a second bug here which triggered the other bug. In [8] (link fixed) VisualEditor automatically added link=File:NYC_Bus_with_%22masks_required%22_sign.jpg for File:NYC Bus with "masks required" sign.jpg when only the caption was edited. The wikilink [[:File:NYC_Bus_with_%22masks_required%22_sign.jpg]] produces File:NYC_Bus_with_"masks_required"_sign.jpg which works in wikitext but goes to the same file, so it would merely be redundant junk code if MediaWiki actually recognized it as a link parameter. I can reproduce it in this:

[[File:NYC Bus with "masks required" sign.jpg|thumb|Bus 1]]
[[File:Bus in Alexandria.jpg|thumb|Bus 2]]

If the spaces in the captions are removed with VisualEditor then a link parameter is added for the file name with quotation marks:

[[File:NYC Bus with "masks required" sign.jpg|thumb|Bus1|link=File:NYC_Bus_with_%22masks_required%22_sign.jpg]]
[[File:Bus in Alexandria.jpg|thumb|Bus2]]

PrimeHunter (talk) 06:03, 9 July 2020 (UTC)[reply]

It is rarely necessary - or even desirable - to use the |link= parameter. In the absence of that param, the MediaWiki software automatically creates a link to the file description page, and this is often required for file attribution purposes. The |link= parameter exists so that this behaviour may be overridden, either by unlinking the file description page or by linking to an entirely different page, either of which would, in the case of File:NYC Bus with "masks required" sign.jpg, effectively violate the terms of its CC BY-SA 4.0 license. --Redrose64 🌹 (talk) 09:06, 9 July 2020 (UTC)[reply]

The link parameter with %22 is not recognized so the default link is used on the image in this case and the bug doesn't break the license. The error is that the link text is shown as caption. PrimeHunter (talk) 09:58, 9 July 2020 (UTC)[reply]

PrimeHunter, thanks for this detailed explanation. I have submitted this apparent VE bug separately, as T257581. If I got anything wrong in there, please add a correction. I have been told by WMF staff that they expect to work on the lengthy backlog of minor (but quite annoying to gnomes who clean up after them) VE bugs in the second half of 2020. We shall see. – Jonesey95 (talk) 14:47, 9 July 2020 (UTC)[reply]

This is not a bug report but an improvement request. When I click "Mark all changes as seen" in my watchlist, the resultant page is not reflected to my Chrome's cache. So if I navigate a different page and click "Go back", the watchlist page shows the content before I clicked "Mark all changes as seen". So it is my routine to click "Reload" after clicking "Mark all changes as seen". Is it possible to reflect the resultant page to my Chrome's cache automatically?―― Phoenix7777 (talk) 00:42, 9 July 2020 (UTC)[reply]

At Gavin McInnes I tried to unaccept two edits. I was told I had. But I hadn't. Tried again and only had the option to accept. Doug Weller talk 14:42, 9 July 2020 (UTC)[reply]

Not long ago (a couple of weeks?), a change was rolled out to how your watchlist is formatted, putting some items in a left-hand column in a monspaced font. What bothers me about it is that the diff and history links come after the page title. Since those links are constant for each entry, it seems they would be better in the mono-spaced side of the page. They would certainly be a lot easier to find. So, two questions. 1) Am I the only one who feels this way, and 2) Is this something that can get changed in per-user CSS, or even in per-project interface definition? -- RoySmith (talk) 14:51, 9 July 2020 (UTC)[reply]

RoySmith, is that skin-specific? I use the default (Vector) and my watchlist view hasn't changed. (From left to right, I see: diff-hist-title-time-bits-editor-edit summary) Schazjmd (talk) 16:17, 9 July 2020 (UTC)[reply]

Schazjmd, Hmmm. I also use vector. I'm not exactly sure what changed, but it certainly has a different appearance than it used to. I assumed some global change was rolled out. Maybe it's just a typography change that caught my eye? -- RoySmith (talk) 16:28, 9 July 2020 (UTC)[reply]

RoySmith, ack, that looks nothing like mine! I really hope it's a glitch and not a change that is going to hit all of us. Schazjmd (talk) 16:42, 9 July 2020 (UTC)[reply]

Tracked in Phabricator
Task T202916

RoySmith, it's just that horrible bug that I keep whingeing to Catrope about. If you click somebody else's link to RecentChanges or watchlist, and that person uses the ugly settings, then your prefs get changed to the ugly system. Go to phab:T202916 for a description and for a bit of Javascript code that will stop this by re-setting your account prefs to non-ugly on every page load. (You can fix it manually in Special:Preferences, but if it keeps happening, then the automated system saves you the trouble of repeatedly fixing it.) Whatamidoing (WMF) (talk) 21:20, 9 July 2020 (UTC)[reply]

Whatamidoing (WMF), That's kind of mind-bogglingly frightening. Basically a code injection bug in a URL, if I understand it correctly. But, I'm not seeing which preference it is that got changed. T202916 talks about Recent Changes, this is Watchlist. -- RoySmith (talk) 18:10, 10 July 2020 (UTC)[reply]

It's "Group changes by page in recent changes and watchlist" at Special:Preferences#mw-prefsection-rc. The Watchlist is, roughly put, implemented as a part of RecentChanges and they share some features. PrimeHunter (talk) 18:23, 10 July 2020 (UTC)[reply]

PrimeHunter, Yeah, that fixed it. As for hiding a Watchlist preference under Recent Changes, well, that's just sub-optimal. -- RoySmith (talk) 01:19, 11 July 2020 (UTC)[reply]

The {{help me}} staff advised me to pose the following how-to question on the Village pump: In Toronto Railway Company#Roster summaries, there is a list of 4 small narrow tables. I would like to put the tables side by side in pairs rather than having them all stacked with a lot of white space to the right. Is there a way to do this? Thanks. TheTrolleyPole (talk) 15:27, 9 July 2020 (UTC)[reply]

Put the small tables inside a larger table having 2 columns (see the rather excessive examples at Help:Table) or this may be simpler: {{col-begin}}{{col-break}} Two tables {{col-break}} Two tables {{col-end}}. See Help:Columns and Example 4 at Template:Col-begin — GhostInTheMachine ^{talk to me} 16:02, 9 July 2020 (UTC)[reply]

Tables are for tabular data, not page layout. Your sugegstion is an accessibility barrier. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:32, 9 July 2020 (UTC)[reply]

Pigsonthewing, Let me just expand on that a bit. The gist is that you need to separate semantics from presentation. Semantics is what the text means. Presentation is what it looks like. Consider that what you write will be consumed in many different ways:

1. Reading it in a web browser on a computer
2. Using any of a number of different CSS skins
3. Reading it on a mobile device.
4. Reading a machine-generated translation to another language
5. A non-sighted person listening to it via text-to-speech technology
6. A minimally-sighted person using text zoom-and-pan technology
7. A computer program doing data-mining or search engine ingestion

By conflating semanic and layout, you make it more difficult for one or more of these consumers. For example, I just looked at Toronto Railway Company on my phone. The main body type was easy to read, but those four tables were too small. I quickly zoomed in so each table was the width of my phone's screen, and they were immediately easy to read. If these were laid out in a 2 x 2 grid of sub-tables, that would have been a mess. Navigating it using text-to-speech would have been neigh on impossible, I would guess.

The right answer is to mark the text up so the semantics are clear, and then rely on presentation tools to handle things properly for the particular device-user combination. See Responsive web design. -- RoySmith (talk) 16:54, 9 July 2020 (UTC)[reply]

Since these are (more or less) the same things at different points in time, it might be possible to combine all of the information into a single medium-size table, with properly declared scope for columns and rows. Whatamidoing (WMF) (talk) 21:25, 9 July 2020 (UTC)[reply]

You can also use Help:Table#Side by side tables to display as many tables as the browser has room for, all four for many desktop users. I did that in [9]. The tables move down when there isn't room. PrimeHunter (talk) 06:23, 10 July 2020 (UTC)[reply]

I recently found out how to make a disambiguation page appear in orange (so I don't link to one by mistake) but the shade of orange is really light. I've seen darker shades of orange that are easier to read. I thought I had changed the link to my talk page in my signature to one of those, but maybe not.— Vchimpanzee • talk • contributions • 18:35, 9 July 2020 (UTC)[reply]

@Vchimpanzee: I assume you are using the "Display links to disambiguation pages in orange" gadget in preferences? If you want to use a different color, uncheck it in your preferences, go to your Special:MyPage/common.css and add the line a.mw-disambig { color: #ff8921; }, and replace "#ff8921" with the color of your choice (e.g. #aa4400). You could also use a background color to highlight it by doing a.mw-disambig { background-color: #ffbb88; } to produce #ffbb88. --Ahecht (TALK
PAGE) 19:04, 9 July 2020 (UTC)[reply]

"#aa4400" is definitely easier to read. Thanks.— Vchimpanzee • talk • contributions • 19:59, 9 July 2020 (UTC)[reply]

Someone else made another suggestion and I made a request here. I like this new orange better because the other color was making me think I was seeing a red link.— Vchimpanzee • talk • contributions • 19:26, 10 July 2020 (UTC)[reply]

@Vchimpanzee: Here's a way of choosing colours. Go to Colorizer, wait a second or two for it to load - you should see about twenty coloured bars, mostly in groups of three, each bar with a slider. At the left there is a sample area, below which is a four-item menu headed "Change color of:", in that, click "Button".

In the main part, the first group of three bars is titled "RGB(A)"; at the bottom of that group there is a row without a slider titled "Hex". At the right of that there is a value, possibly #a96836 - replace that with the word white. Remember this location, we'll use it again - we can call it the "Hex value".

In the "Change color of:" menu, click "Text" - notice that all the slider bars change. Go again to the Hex value, and alter it to the word orange.

Now use your mouse to drag the sliders around, using most of the 20 sliders - but leave the very last one (titled "Alpha/Opacity") hard over to the right, showing a value of 100. Observe how moving one slider causes several of the others to move; as this happens, the values to the right of the sliders change to suit; notice that the sample area also changes.

When you are happy with the text colour, you can use your mouse to copy the Hex value to your clipboard, this may then be used instead of #ff8921 in the rule a.mw-disambig { color: #ff8921; } mentioned above. --Redrose64 🌹 (talk) 19:56, 10 July 2020 (UTC)[reply]

Refill2 is working if you use this link which is nice. OTOH when you use the link in the {{Cleanup bare URLs}} to get the tool running it still goes to a 404 message. With my limited (very) knowledge of things I made this edit to try and connect the template to the new refill2 link but it did not work. If anyone knows what to do to make this update work it will save some copy pasting for those of us who work on formatting bare urls. Thanks. MarnetteD|Talk 20:55, 9 July 2020 (UTC)[reply]

MarnetteD, I think it should be fixed now. – BrandonXLF (talk) 21:04, 9 July 2020 (UTC)[reply]

Thanks so much BrandonXLF. That is such a help. It is gonna take a few days to clear the backlog on these but your fix is going to make that task much easer!! Cheers. MarnetteD|Talk 21:08, 9 July 2020 (UTC)[reply]

Yes, thanks so much, the provided link above works for me. I really appreciate the wonderful help. Thank you. Caro7200 (talk) 21:10, 9 July 2020 (UTC)[reply]

• The link at the top of User:Zhaofeng Li/reFill ... toollabs:refill, which goes to https://refill.toolforge.org/ ... still gives 404 errors after attempting to run reFill on a page. Steel1943 (talk) 21:24, 9 July 2020 (UTC)[reply]
  • ...Eh, looks like that (an edit by me) worked and took care of it. Steel1943 (talk) 21:27, 9 July 2020 (UTC)[reply]
    • expand bare references is not working for me. Just tried again and still get a 404 page. Grrrr. I am not a techy person, I just like to edit....Tribe of Tiger ^{Let's Purrfect!} 05:59, 10 July 2020 (UTC)[reply]

As with Wikipedia:Village pump (technical)/Archive 182#logged out automatically two weeks ago, I was forcibly logged tout at approximately 21:47 (UTC) today. --Redrose64 🌹 (talk) 21:52, 9 July 2020 (UTC)[reply]

Ditto. SarahSV ^(talk) 21:54, 9 July 2020 (UTC)[reply]

Me too, sounds like it might be everyone. Graeme Bartlett (talk) 21:55, 9 July 2020 (UTC)[reply]

@Graeme Bartlett, SarahSV, and Redrose64: This was everyone, yes; see this wikitech-ambassadors post. Naypta ☺ | ✉ talk page | 21:57, 9 July 2020 (UTC)[reply]

Same. Wikipedia might want to fix this. Amaury • 21:57, 9 July 2020 (UTC)[reply]

Me too. And not just Wikipedia, but everything connected - Wikiserve, Commons, etc — Maile (talk) 22:00, 9 July 2020 (UTC)[reply]

This was part of further measures to respond to that incident. https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2020-July/002326.html --AntiCompositeNumber (talk) 22:01, 9 July 2020 (UTC)[reply]

If a security issue is so significant that it merits this level of disruption, we should be told about it. It may have to come afterward if time is of the essence but it should still be communicated. ElKevbo (talk) 22:02, 9 July 2020 (UTC)[reply]

Second that. I had put the log-out a couple of weeks ago down to "Oh well, I suppose it could be a year since I last logged in" and had no idea there had been such a major screw-up. DuncanHill (talk) 22:18, 9 July 2020 (UTC)[reply]

Absolutely. This is ridiculous. It's not hard to put up a message everyone can see. Doug Weller talk 09:07, 10 July 2020 (UTC)[reply]

I have a small suggestion. Since all (I think) have been logged out, I think a banner needs to be displayed in all wikis stating the link of Wikitech-Ambassador mailing list message and must ask registered users to login again. This might be unknown to normal users as they keeps editing without knowing that they are currently editing as an IP. I have seen some edits from recent changes which belongs to that category. So I think a banner needs to be made wiki-wide. Adithyak1997 (talk) 11:33, 10 July 2020 (UTC)[reply]

Well you do get MediaWiki:Anoneditwarning on every page if you try to edit w/o being logged in. — xaosflux ^Talk 12:49, 10 July 2020 (UTC)[reply]

I too found myself logged out yesterday, for the 2nd time in five days. Previous to these last two, I had not been logged out in a year or more. It's mysterious. And the one yesterday was worse because I was in the middle of trying to do an edit. Johnsmith2116 (talk) 18:59, 10 July 2020 (UTC)[reply]

Shtardusty's one and only edit was to create CALiENS [10]. How did they do this? Since they were not autoconfirmed, they shouldn't have been able to create anything in mainspace. Normally the answer is that they created it in draft space and it was moved, but I can't find any evidence in the logs of such a page move. -- RoySmith (talk) 02:02, 10 July 2020 (UTC)[reply]

They created it on 6 April 2016. When was the ability for non-autoconfirmed users to create pages removed? Johnuniq (talk) 02:21, 10 July 2020 (UTC)[reply]

On or after 18 April 2018 for WP:ACPERM, and earlier during WP:ACTRIAL. BlackcurrantTea (talk) 02:41, 10 July 2020 (UTC)[reply]

Andrybak and I discovered earlier that the audio player does not work inside the collapse box:

Whatever is happening doesn't affect video. It also doesn't affect audio if the box is autoexpanded:

I don't know of any applications with an audio file inside a collapsed box (other than the testcases page where we found this), but just wanted to throw it out here in case there's an easy fix available. Cheers, {{u|Sdkb}} ^talk 05:16, 10 July 2020 (UTC)[reply]

I just got thanked for a three-year-old edit by Subzerosmokerain. Looking at that old edit, here, shows a page that is a mixture of my talk page at that time, and Tintor2's user page. The change happens at the point on the page where that edit was -- the end of the page at the time, most likely. Anyone have any idea what's happened to this rev? The next rev seems fine. Mike Christie (talk - contribs - library) 13:25, 10 July 2020 (UTC)[reply]

All pages can be transcluded, not just templates. {{User:Tintor2|Tintor2}} has curly brackets so it transcludes User:Tintor2 (with an unnamed parameter Tintor2 which does nothing). You fixed it in the other edit you link. PrimeHunter (talk) 14:41, 10 July 2020 (UTC)[reply]

Damn; I knew that and had even seen it happen before. Thanks for the reminder. Mike Christie (talk - contribs - library) 17:29, 10 July 2020 (UTC)[reply]

Can someone help me get back the draft article for Gaza Sky Geeks? It was submitted to the article creation board in 2018 and looked like this when it was denied: [11]. But then it was deleted or something so now the draft looks like this: Draft:Gaza Sky Geeks So a lot of draft content has been lost. ImTheIP (talk) 17:57, 10 July 2020 (UTC)[reply]

ImTheIP, The right way is to make a request at WP:REFUND, but making you do that would be a waste of perfectly good bureaucracy. I've restored the old versions. Check the draft's history. -- RoySmith (talk) 18:04, 10 July 2020 (UTC)[reply]

Thanks! ImTheIP (talk) 18:05, 10 July 2020 (UTC)[reply]

It would probably be rude to change the name of a section on a talk page just so a link to the section can be provided.

Here is the problem. Now there may be a way to change the link, but I don't know what that is. — Vchimpanzee • talk • contributions • 18:48, 10 July 2020 (UTC)[reply]

You need to URL encode the offending characters. In this case that's the left and right square brackets. --Izno (talk) 18:53, 10 July 2020 (UTC)[reply]

(edit conflict)@Vchimpanzee: Encode it, like this. Square brackets become %5B and %5D if before the hash, .5B and .5D if after the hash. --Redrose64 🌹 (talk) 18:56, 10 July 2020 (UTC)[reply]

Also, you can use the {{anchor}} template to add an invisible named anchor you can link to. --Masem (t) 19:01, 10 July 2020 (UTC)[reply]

Thank you.— Vchimpanzee • talk • contributions • 19:04, 10 July 2020 (UTC)[reply]

Redrose64 I had to copy what you did on another talk page because somehow I couldn't make it work. Wait, I see what I did wrong. I thought I added the space and I didn't.— Vchimpanzee • talk • contributions • 19:12, 10 July 2020 (UTC)[reply]

Yes, the spaces need to be left alone. --Redrose64 🌹 (talk) 19:20, 10 July 2020 (UTC)[reply]

@Vchimpanzee and Redrose64: Numeric character references ([, ]) work better in this case, preserving the look. Nardog (talk) 08:05, 11 July 2020 (UTC)[reply]

Until now the links to articles in other languages had been organized (at least in my settings) according to their wiki code (en, fr, ru, etc). But just looking now, and it seems to have randomized to have no discernible order. Did something change with it that I missed, and/or is there a way to set it back? I really prefer having it alphabetized, it's easier to find interwiki links that way. Kaiser matias (talk) 20:40, 10 July 2020 (UTC)[reply]

The sort order for this is, I believe, given at meta:MediaWiki:Interwiki config-sorting order-native-languagename. --Redrose64 🌹 (talk) 21:28, 10 July 2020 (UTC)[reply]

For some reason, the sorting depends on an article. In Battle of the Bagradas River (255 BC), for example, it's new, but in Apple, for instance, it's old where Russian, for example, is placed below Portuguese. In Battle of the Bagradas River Russian is above Portuguese, among top three. Very strange. And I support restoring the previous familiar sorting. Brandmeister^talk 21:41, 10 July 2020 (UTC)[reply]

The non-alphabetical sitelink/interwiki language order is actually bug phab:T257625. It is indeed supposed to be alphabetical.--Snaevar (talk) 00:27, 11 July 2020 (UTC)[reply]

Thanks for clarifying. Brandmeister^talk 07:29, 11 July 2020 (UTC)[reply]

• While we're here, let's go to first principles — what should the order ideally be? The main thing I'm normally doing when looking at a page in a foreign language is trying to find a version more comprehensive than the English one, so I'd argue the best sorting order might be by wikitext length. If we really wanted to keep the ordering the same between all pages, we might order the language editions by number of active editors (since doing it by number of articles would get warped by bot use). I'm not sure of the technical feasibility of any of that, but we should be thinking about what we want before moving to the technical conversation. {{u|Sdkb}} ^talk 02:12, 12 July 2020 (UTC)[reply]
  • Alphabetical by displayed name in English, just as it is supposed to be. See meta:MediaWiki talk:Interwiki config-sorting order-native-languagename. If a reader is looking for an article in another language, that's the easiest way for them to find it. As for your other suggestions, that way, I fear, lies madness. A small shift in the number of active editors (and who would define 'active'?) could quickly change the relative positions of two small wikipedias. Dueling sockpuppet teams can vie for higher placement. Longer articles? By all means, fill them with junk, because then they'll get higher placement. They may be very low-quality indeed, but they're longer, and that's what counts? No. Really, no. BlackcurrantTea (talk) 04:20, 12 July 2020 (UTC)[reply]

Possible problem at South Pole Wall => "Unable to fetch revision data" (re upper-most page summary, right below the article title)? - Drbogdan (talk) 23:35, 10 July 2020 (UTC)[reply]

SOLVED: Problem now seems ok - Thanks to anyone who might have helped with this - Stay Safe and Healthy !! Drbogdan (talk) 03:45, 11 July 2020 (UTC)[reply]

#ifexist doesn't seem to work for files on Commons? Is there an alternative? I wanted to make {{emoji}} able to detect if its default, Emojione, doesn't have a certain emoji.

E.g.

 | [[File:{{#switch: {{{theme|{{{2}}}}}}
 | twitter      = Twemoji12 {{lc:{{{1|}}}}}
 | noto         = Emoji u{{lc:{{{1|}}}}}
 | noto 4.4     = Noto Emoji KitKat {{lc:{{{1|}}}}}
 | noto 5.0     = Noto Emoji Lollipop {{lc:{{{1|}}}}} <!-- Note: Includes only the updated 5.0 emojis. The other emojis on that version are identical to 4.4 versions and the 5.0 files are red-linked. Please update this if you can find a way. -->
 | noto 8.0     = Noto Emoji Oreo {{lc:{{{1|}}}}}
 | noto 9.0     = Noto Emoji Pie {{lc:{{{1|}}}}}
 | android      = Android Emoji {{lc:{{{1|}}}}}
 |  {{uc:{{{1|}}}}}
 | one bw       = Emojione BW {{uc:{{{1|}}}}}
 | one v1       = Emojione1 {{uc:{{{1|}}}}}
 | fx           = Fxemoji u{{uc:{{{1|}}}}}
 | #default     = {{#ifexist:File:Emojione {{uc:{{{1|}}}}}.svg|Emojione {{uc:{{{1|}}}}}|Twemoji12 {{lc:{{{1|}}}}}}}

Emojione is missing many emoji, because it became proprietary at some point... but wasn't when the template was made. I don't want to just WP:BOLDly change it to use e.g. Twitter emoji, which are complete, because it will change many, many pages without discussion. So...what can we do? Psiĥedelisto (talk • contribs) ^{please always ping!} 01:39, 11 July 2020 (UTC)[reply]

#ifexist for files on Commons works if you use Media: instead of File:. Nardog (talk) 02:03, 11 July 2020 (UTC)[reply]

Hi, Given Dispensers tools now all seem to be history shouldn't the DPL bot be updated to remove the Dabsolver links ?. The bots operator isn't very active so wasn't sure if this could be done for them or whether there's nothing that can be done other than recreate the bot without the links? (which would be silly tbh), Thanks, –Davey2010^Talk 09:43, 11 July 2020 (UTC)[reply]

Using www......wikiarticlename#sectionname fails in some cases: the wrong destination section is jumped to/displayed.

Example: https://en.wikipedia.org/wiki/SD_card#SDXC jumps to SD_Card section "2009–present: SDXC" (section 6) instead of the later section "SDXC" (section 10).

Reason: Wikicode is generating a spurious HTML <span>...</span> element containing only the incorrect target id in the earlier section. This 'hijacks' the jump/link.

In more detail: The HTML in section 6 is

<h3>
 <span id="2009.E2.80.93present:_SDXC"></span>
 <span class="mw-headline" id="2009–present:_SDXC"> <span id="SDXC"></span> 2009–present: SDXC 
 <span class="mw-editsection">
  <span class="mw-editsection-bracket">[</span>
  <a href="/w/index.php?title=SD_card&action=edit&section=6" title="Edit section: 2009–present: SDXC">edit</a>
  <span class="mw-editsection-bracket">]</span>
 </span>
</h3>

The HTML in section 10 is

<h3>
 <span class="mw-headline" id="SDXC">SDXC</span>
 <span class="mw-editsection">
  <span class="mw-editsection-bracket">[</span>
  <a href="/w/index.php?title=SD_card&action=edit&section=10" title="Edit section: SDXC">edit</a>
  <span class="mw-editsection-bracket">]</span>
 </span>
</h3>

if the HTML code <span id="SDXC"></span> is removed 'by hand' from the generated HTML then jumping/linking to both the sections works correctly with,

https://en.wikipedia.org/wiki/SD_card#2009–present:_SDXC

and

https://en.wikipedia.org/wiki/SD_card#SDXC

respectively.

Error reproduced in Firefox 76.0 and Slimjet 26.0.3.0 (based on Chromium 80.0.3987.87) under Ubuntu 18.04

Somewhat bizarrely, with Navigation popups installed, mousing over the above links shows the correct section in both cases! But clicking on them jumps to section 6 in both cases. Hedles (talk) 12:56, 11 July 2020 (UTC)[reply]

The section-header for section 6 of SD card is

==={{Anchor|SDXC}} 2009–present: SDXC ===

Someone has explicity added a {{anchor}} for #SDXC there. Each of the product-names links to the entry in §History, which conflicts with their use as actual section-titles later. This problem is noted in the second entry of Template:Anchor#Limitations. DMacks (talk) 13:16, 11 July 2020 (UTC)[reply]

Navigation popups gives a different result because it doesn't look for an anchor in the html but for a section name in the wikitext. This works for https://en.wikipedia.org/wiki/SD_card#SDXC where it finds ===SDXC===. But it fails for https://en.wikipedia.org/wiki/SD_card#2009–present:_SDXC where it doesn't find ==={{Anchor|SDXC}} 2009–present: SDXC ===. It just shows the lead in that case. PrimeHunter (talk) 06:21, 12 July 2020 (UTC)[reply]

It appears that Wikimedia has recently turned off the ability to edit or even view the source of an old version on Commons.

I don't like this feature at all. How do I disable it? Magog the Ogre (t • c) 12:19, 12 July 2020 (UTC)[reply]

Magog the Ogre, leaving aside that this is en.wiki and not commons, I just tested four different types of pages there and they are fine. Could you give an example or screenshot? Elizium23 (talk) 12:32, 12 July 2020 (UTC)[reply]

https://commons.wikimedia.org/w/index.php?title=File:Sheetz_footprint.png&action=edit&oldid=170858190 <-- this page always redirects to mcrrestore. It's a pain when trying to manually merge changes. Also VPT is a global board so I'm not sure why you care which wiki it is. Magog the Ogre (t • c) 12:39, 12 July 2020 (UTC)[reply]

Magog the Ogre, commons:Help Desk#How to view old source text when there is mediainfo might be instructive. Elizium23 (talk) 12:43, 12 July 2020 (UTC)[reply]

Thank you. Magog the Ogre (t • c) 12:51, 12 July 2020 (UTC)[reply]

@Magog the Ogre: The top of this page actually says: "The technical section of the village pump is used to discuss technical issues about Wikipedia." The issue doesn't exist at Wikipedia although it affects some files used here. The edit notice here says: "Where did you encounter the problem? Please add links when possible." Always link the page you post about no matter which wiki it's at. If you think it's a general issue then always link a page where you saw the issue so helpers like Elizium23 don't waste time trying to guess that you are posting about. This issue only affects some of the Commons file pages. PrimeHunter (talk) 13:21, 12 July 2020 (UTC)[reply]

​{{Dablinks}} has a bunch of nonfunctional links as can be seen at Lake Estancia. Does someone know of a replacement tool? Jo-Jo Eumerus (talk) 13:46, 12 July 2020 (UTC)[reply]

They are privately hosted tools by Dispenser who hasn't edited since March. His domain dispenser.info.tm is not working. See User talk:Dispenser#info.tm. It mentions an IP address which may work but I'm not sure we want to link directly to an IP address in common templates, and I get browser security warnings there. With the IP address, https://dispenser.info.tm/~cgi-bin/dablinks.py?page=Lake_Estancia becomes https://69.142.160.183/~cgi-bin/dablinks.py?page=Lake_Estancia, and https://dispenser.toolforge.org/cgi-bin/dab_solver.py?page=Lake_Estancia becomes https://69.142.160.183/cgi-bin/dab_solver.py?page=Lake_Estancia. I didn't make them links. Examine at your own risk. PrimeHunter (talk) 14:11, 12 July 2020 (UTC)[reply]

Dispenser (either live manually, or maybe just an automatic process) edit on commons each month. I left a note on usertalk there. Hopefully they will respond so we can continue/return to using these tools. DMacks (talk) 16:28, 12 July 2020 (UTC)[reply]

I just got a notification that I signed into Wikipedia from a device I haven't used lately. I have used this device every single day since we were told to stay home, except when I took a brief vacation after we were told, perhaps wrongly, that it was safe to do so.

I use an alternate identity to thank people (and make it clear on the user page who I am) because it's annoying to constantly see the word "thank" in every single edit in histories, and I have done what is necessary to not see the "thank" message.

But I have signed in as that person from this device several times in recent weeks.— Vchimpanzee • talk • contributions • 17:48, 12 July 2020 (UTC)[reply]

The message was probably MediaWiki:Notification-loginnotify-login-success-email-subject and MediaWiki:Notification-header-login-success. I don't know the rules but it may involve a user agent which can change for different reasons like updating the operating system or changing browser. The code in User:Vchimpanzee/common.css still gives you a thank link in diffs so there is no need to change account to thank users. You can also add ?safemode=1 or &safemode=1 (if the url already has a ?) to a url to omit local scripts and CSS. This will display thank links in a page history while you view that url. PrimeHunter (talk) 18:38, 12 July 2020 (UTC)[reply]