Wikipedia:Village pump (technical): Difference between revisions
→Quarry down?: Comment |
→Quarry down?: {{tracked}} |
||
Line 652: | Line 652: | ||
==Quarry down?== |
==Quarry down?== |
||
{{tracked|T375988}} |
|||
Hello, Tech aficianados, |
Hello, Tech aficianados, |
||
Revision as of 05:58, 30 September 2024
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.
Frequently asked questions (see also: Wikipedia:FAQ/Technical) Click "[show]" next to each point to see more details.
|
Dark mode when logged out of Wikipedia
When logged out, in dark mode, at {{Soulfly}}, the actual link for Soulfly is an extremely dark grey that is difficult to see on a black background. It was not this way before. Does anyone know how to fix this? --Jax 0677 (talk) 15:47, 5 September 2024 (UTC)
- See the notes and linked pages from when you recently asked about this: Wikipedia:Village_pump_(technical)/Archive_214#Dark_Mode_Text. — xaosflux Talk 15:56, 5 September 2024 (UTC)
- Thanks, I assume that we will have to wait our turn.
- The issue is fixed when I am actually LOGGED IN, but not fixed when I am logged OUT. --Jax 0677 (talk) 16:11, 5 September 2024 (UTC)
- I made this edit yesterday to improve display of self links in navboxes. I will try to fix this fully today since this specific navbox keeps coming up. Izno (talk) 16:10, 5 September 2024 (UTC)
- This should be fixed for this template. Izno (talk) 17:37, 5 September 2024 (UTC)
Enhanced editnotice loader
I worked on a module that would serve as an enhanced editnotice loader for Wikipedia. See testwiki:Module:Editnotice_load and Module:Editnotice load (which is an exact copy). Features include category editnotices, better group notices, and editnotices by page ID (which would reduce the need to move pages around).
I want to get further feedback on this loader before it inevitably gets implemented. Please check out the testwiki. It should be backwards compatible with the way we do things, but I would like checks for this first.
If this is to be implemented, there will need to be a couple of changes made, including to:
- Template:Editnotice load (would need to be replaced with
{{#invoke:editnotice load|main}}
) - Template:Editnotice load/notext (would need to redirect to Template:Editnotice load, or should call {{editnotice load}} but with the parameter "notext=yes")
- Template:Editnotice/notice (would need to be updated to match that on testwiki)
- MediaWiki:Noarticletext-nopermission (should be updated with the following addendum:
{{#invoke:editnotice load|protectionEditnotice}}
) - MediaWiki:Protectedpagetext (would need to be updated to match that on testwiki)
- MediaWiki:Cascadeprotected (would need to be updated to match that on testwiki)
- Template:Editnotices/Group/Template:Editnotices (would need to be updated to match that on testwiki)
- MediaWiki:Titleblacklist-custom-editnotice (would need to be updated to match that on testwiki)
This would make the editnotice loader much more robust.
Immediately, in preparation for this, I would consider adding the following category editnotices templates:
{{BLP editintro}}
Anything else? Awesome Aasim 19:06, 9 September 2024 (UTC)
- Some documentation on how it works from a user's perspective would be helpful, in order to understand the context and how it would be used in practice, including how security restrictions are enforced. On a side note, I'm not sure that its deployment is "inevitable". isaacl (talk) 22:03, 9 September 2024 (UTC)
- I have some testcases on testwiki. For best results, view when logged out and inspect the HTML when logged in.
- testwiki:Taylor Swift should be a good example of me getting category editnotices working. testwiki:Protected title and testwiki:Protected title2 show the protection editnotice on both the create screen and on the "does not exist" screen when a title is protected from creation for other reasons.
- testwiki:Special:EditPage/A should show the page notice from testwiki:Template:Editnotices/PageID/54370 (which is for A). You can also see I renamed previous "page notice"s to "title notice"s because the way page notices are bound to currently are actually to titles, not pages. The new "page notice" will remain bound to a specific page because it uses PageID. There will be no need to update the title notices for pages that exist. On the other hand, for pages that don't exist, the title notice will need to be kept up to date. Awesome Aasim 04:01, 10 September 2024 (UTC)
- I can't tell from the article page how to use the feature: where the edit notice lives, how will access be limited, and so forth. Thus it's hard to evaluate the feature without knowing the maintenance cost. isaacl (talk) 09:58, 10 September 2024 (UTC)
- The editnotices live in the same pseudo-space: Template:Editnotices/. See testwiki:Module:Editnotice load/config.
- I also moved the editnotice links to a collapsible box because the number of creatable editnotices has gotten relatively high after adding category notices. Awesome Aasim 13:16, 10 September 2024 (UTC)
- OK, I see there's now a link above the edit notice point to its location, so category-based notices are grouped under a "Category" subpage. What are the enhancements for the group-based notices? isaacl (talk) 18:33, 10 September 2024 (UTC)
- There is less ambiguity in how they are handled. For example, on testwiki:Template:A/B/C/D/E, there are five different group editnotices that can be created. So if there is a page where it is desirable that the group Template:A/B needs one group notice, and Template:A/B/C needs another group notice, and Template:A/B/D needs another group notice, that can now be done; there will be one common group notice and two separate group notices for subpages. Awesome Aasim 19:21, 11 September 2024 (UTC)
- OK, I see there's now a link above the edit notice point to its location, so category-based notices are grouped under a "Category" subpage. What are the enhancements for the group-based notices? isaacl (talk) 18:33, 10 September 2024 (UTC)
- I can't tell from the article page how to use the feature: where the edit notice lives, how will access be limited, and so forth. Thus it's hard to evaluate the feature without knowing the maintenance cost. isaacl (talk) 09:58, 10 September 2024 (UTC)
- I would suggest to phase the rollout into stages, and creating a test plan to ensure nothing regressed. Editing this many interface pages and fully protected templates at once sounds like too much work for an admin to volunteer to. For instance, the specific category editnotices you mention can be left for later as we already have a decent system to handle those categories.
Immediately, in preparation for this, I would consider adding the following category editnotices templates
this cannot be done immediately as they also need to be removed from Module:Mainspace editnotice, else they would show up twice when the rest of the changes are deployed. – SD0001 (talk) 08:01, 10 September 2024 (UTC)- I actually think this might be something that is better done all in one go. Removing the two category editnotices from Module:Mainspace editnotice should be kind of a no-brainer after the rollout. The way that the module currently does these checks, checking the unparsed wikitext, currently sucks.
- Do you have an idea for a Scribunto test runner for Module:Editnotice load to ensure that everything works with demo editnotices? Awesome Aasim 16:53, 13 September 2024 (UTC)
Thoughts on Docbunto?
I encountered a powerful autodoc tool on Fandom Dev Wiki called Docbunto, and I have been able to get some changes to make it work on Test Wikipedia. I think it would be very great to have an autodoc tool like Docbunto on Wikipedia to help speed up the process of writing module documentation. But the key feature I like is the ability to transclude templates and similar on Lua pages.
I don't think it is ready for English Wikipedia yet but maybe with a few changes it can be very feature rich and ready. Yeah we are not exactly a code repository, but we do have thousands of modules used across articles that would be helpful to have auto documentation for. Awesome Aasim 18:21, 17 September 2024 (UTC)
- Wiktionary uses something similar. See wikt:Module:module documentation.
But the key feature I like is the ability to transclude templates and similar on Lua pages.
As for this, we can already do this on this wiki: Module:Module wikitext. – SD0001 (talk) 20:15, 17 September 2024 (UTC)- Another improvement we can do over wiktionary is take advantage of line numbers now being linkable. Ideally, the generated docs of exported functions should include links to their source code definitions. – SD0001 (talk) 20:18, 17 September 2024 (UTC)
As for this, we can already do this on this wiki: Module:Module wikitext.
That is very bodgy, and it doesn't entirely make sense to me how this works or why this should work. But then, an autodoc module rendering module comments is also very bodgy, although less bodgy because reading out comments to parse from the module is less likely to break than reading out variables from the documentation module after setting them in "addText". Module comments should be taken advantage of in the parser. I did open a task (and submit my first patch to MediaWiki to complete it) for having MediaWiki only parse the contents of CSS and JS comments, see phab:T373834 (and kindly do please send more feedback on how I can improve that patch!) Awesome Aasim 00:21, 18 September 2024 (UTC)
- Another improvement we can do over wiktionary is take advantage of line numbers now being linkable. Ideally, the generated docs of exported functions should include links to their source code definitions. – SD0001 (talk) 20:18, 17 September 2024 (UTC)
- We considered generating documentation from LuaDoc when creating Scribunto, but we decided not to for the same reasons most documentation pages here are on /doc subpages instead of being inline in the template page: inlined docs can't be protected separately from the module/template and any edit to inlined docs means any pages using the module/template have to be reparsed. Anomie⚔ 23:50, 17 September 2024 (UTC)
- I'd figure. I think of this inline doc as a good starting point for most Lua modules but ultimately there should be additional documentation that goes beyond the default functions and describes what the module exactly does. Awesome Aasim 23:53, 17 September 2024 (UTC)
- Yeah, being able to edit documentation without going through edit requests would be nice, even though so would be autogenerating doc sections for functions. Nardog (talk) 01:20, 18 September 2024 (UTC)
- Automated cat herding is not going to work at Wikipedia. Imagine forcing every module to have comments in a fixed format with extra gunk to be machine parsable. Johnuniq (talk) 02:27, 18 September 2024 (UTC)
- It is really bad practice to not put comments in code. Autodoc obviously won't work if there aren't any properly formatted comments. The goal of autodoc is to document functions and variables and more importantly module exports. Even functions in use by other modules. It never is intended to replace the module documentation page at the top of each; just supplement it. Awesome Aasim 03:05, 18 September 2024 (UTC)
- Yes, useful comments are great. What I meant was, it would be very difficult to get independent editors to use a fixed format. Also, I don't think documenting all functions and variables is achievable or even desirable, for example, due to the inevitable drift between hopeful comments and actual code. I do agree that exports should be documented and I once argued strongly that a module (I forget where now) should not have every function exported due to ensuing confusion and maintenance issues. I lost that argument. Johnuniq (talk) 03:34, 18 September 2024 (UTC)
- There is a few related stuff I can think of.
- Automatically making a list of variables is actually easy. The hard part is getting arguments in loops. See is:Module:Templatedata fyrir skriftu, which can create basic templatedata (containing only a list of variables) with the code {{#invoke:Templatedata fyrir skriftu|main|''name of module with namespace''}}.
- There is also an request to WMF at meta:Community_Wishlist/Wishes/Document_ALL_the_modules! about this same subject.
- Come to think of it some of doc.wikimedia.org is actually built on similar logic to docbunto. Snævar (talk) 19:08, 19 September 2024 (UTC)
- Why not both? If there's comments in code formatted in a certain way, show them in /doc, but also allow overriding or appending to it without having to edit the module directly. Nardog (talk) 03:37, 18 September 2024 (UTC)
- +1. I do think having both is useful. We can provide an end user overview at the top of the module documentation page, and a developer's overview in the autodoc. Something similar to how I implemented autodoc on testwiki:Module:Docbunto and testwiki:Module:i18n. There should be some sort of disclaimer that the documentation is auto generated and the contents can be overridden. Awesome Aasim 14:42, 18 September 2024 (UTC)
- I did a little bit more work on the module (not really any), and I am wondering if the module can be imported from testwiki to English Wikipedia? We may have to update some of the attribution links to point to Fandom users, but not much else. Awesome Aasim 01:23, 25 September 2024 (UTC)
- You are the only contributor on testwiki. Just copy it. Looks like you've modified Module:Documentation on testwiki to make it automatically show the generated docs. It may be more intuitive to not do that and instead have /doc subpages call the autodoc module (the way it's set up on wiktionary), enabling the automatic and manually written docs to co-exist, making it clearer where the autodoc came from, avoiding the weirdness of a [create] button in the documentation header showing up even when the documentation seemingly exists, etc. – SD0001 (talk) 04:13, 25 September 2024 (UTC)
- But the first edit at testwiki includes an edit summary with a link to the source. That should be retained. The subsequent edits may as well also be retained in the history here. I'm still dubious about whether automatic documentation can be helpful at Wikipedia but having it here would allow live demos. Johnuniq (talk) 05:37, 25 September 2024 (UTC)
- Problem: That module is at testwiki which does not appear as an option at Special:Import. Only test2wiki is available (it was added in February 2013 when Scribunto appeared here). An alternative would be for Awesome Aasim to duplicate the first edit here, with its edit summary, then make another edit to include the current version. Johnuniq (talk) 05:58, 25 September 2024 (UTC)
- Yeah and there are other problems that mean it won't be ready for use right away. See testwiki:Module:Documentation's autodoc, for example.
- I still managed to get it onto English Wikipedia so that we can all work together to make it robust. I actually see why the original i18n module was deleted, while the one on Fandom and on other Wikimedia projects was not: it was too simple.
- I think it will require some sort of consensus to turn this on by default, but at least we have something to start. Awesome Aasim 07:00, 25 September 2024 (UTC)
- Problem: That module is at testwiki which does not appear as an option at Special:Import. Only test2wiki is available (it was added in February 2013 when Scribunto appeared here). An alternative would be for Awesome Aasim to duplicate the first edit here, with its edit summary, then make another edit to include the current version. Johnuniq (talk) 05:58, 25 September 2024 (UTC)
- But the first edit at testwiki includes an edit summary with a link to the source. That should be retained. The subsequent edits may as well also be retained in the history here. I'm still dubious about whether automatic documentation can be helpful at Wikipedia but having it here would allow live demos. Johnuniq (talk) 05:37, 25 September 2024 (UTC)
- You are the only contributor on testwiki. Just copy it. Looks like you've modified Module:Documentation on testwiki to make it automatically show the generated docs. It may be more intuitive to not do that and instead have /doc subpages call the autodoc module (the way it's set up on wiktionary), enabling the automatic and manually written docs to co-exist, making it clearer where the autodoc came from, avoiding the weirdness of a [create] button in the documentation header showing up even when the documentation seemingly exists, etc. – SD0001 (talk) 04:13, 25 September 2024 (UTC)
- I did a little bit more work on the module (not really any), and I am wondering if the module can be imported from testwiki to English Wikipedia? We may have to update some of the attribution links to point to Fandom users, but not much else. Awesome Aasim 01:23, 25 September 2024 (UTC)
- +1. I do think having both is useful. We can provide an end user overview at the top of the module documentation page, and a developer's overview in the autodoc. Something similar to how I implemented autodoc on testwiki:Module:Docbunto and testwiki:Module:i18n. There should be some sort of disclaimer that the documentation is auto generated and the contents can be overridden. Awesome Aasim 14:42, 18 September 2024 (UTC)
- It is really bad practice to not put comments in code. Autodoc obviously won't work if there aren't any properly formatted comments. The goal of autodoc is to document functions and variables and more importantly module exports. Even functions in use by other modules. It never is intended to replace the module documentation page at the top of each; just supplement it. Awesome Aasim 03:05, 18 September 2024 (UTC)
- Automated cat herding is not going to work at Wikipedia. Imagine forcing every module to have comments in a fixed format with extra gunk to be machine parsable. Johnuniq (talk) 02:27, 18 September 2024 (UTC)
table-caption minerva issue
On screens below width 640px there are two related issues with table captions in Drummully#Statistics on mobile, ie https://en.m.wikipedia.org/wiki/Drummully#Statistics.
- In both tables, the caption only spans the first column.
- In the first table, the caption is below the column headers.
The cause is the user agent's default display ...
caption { display: table-caption;
... is overridden by a Minerva stylesheet
@media screen and (min-width: 640px) { .content caption { display: block
When I comment out that line in my Browser developer settings, both tables look fine.
The CSS file's URL is
I dunno where the corresponding source is, or whether this is a Wikipedia or MediaWiki issue, or if there is a defect logged and/or a workaround available. jnestorius(talk) 16:05, 18 September 2024 (UTC)
- The caption being set to display block has always been weird to me; the other display blocks in Minerva make some sense (but I also think I've played around with this before and come to the conclusion that it was necessary?? memory is weird on this point).
- skins.minerva.base.styles/content/tables.less is the source. Izno (talk) 16:32, 18 September 2024 (UTC)
- Captions should be either
display:table-caption;
ordisplay:none;
. Nothing else is sensible. --Redrose64 🌹 (talk) 19:39, 18 September 2024 (UTC)
- Captions should be either
- TLDR: The issue is the inline style adding display: inline-table which is interfering with Minerva's ability to make the table responsive on a mobile device. Please move this to a TemplateStyle so that it only applies at a suitable breakpoint and does not break the display on mobile.
- Longer version: On mobile, since a table doesn't fit in the screen, presenting them to mobile devices becomes tricky. The way we approach this general in MediaWiki sites, it to convert the display property of all table elements to block-based layouts rather than table-based layouts. Applying display block to the table caption, will ensure that it does not require horizontal scrolling to be viewed and will span multiple lines if needed. While this might seem strange is a pretty widely recommended and sensible practice.
- The bug here IMO is not the table caption - it's the use of display inline-table. If you load this article on a mobile device, and expand sections you'll see that this introduces horizontal scroll on the page e.g. the table breaks the content of the whole article. e.g. the whole article is not mobile friendly (note the whitespace to right of chrome in this screenshot: https://phabricator.wikimedia.org/F57532981).
- Inline styles as always interfere with a lot of the logic we have to optimize content. As with dark mode where use of any kind of color can break dark mode display - using display or width or height properties interfere with the responsive behaviour and I would personally recommend always using mw:TemplateStyles to express these. 🐸 Jdlrobson (talk) 00:07, 24 September 2024 (UTC)
- @Jdlrobson: the bug here is also in having
caption { display: block }
style as well. See ru:Амстердам#Климат on mobile for where it breaks easily. stjn 18:19, 24 September 2024 (UTC)- Thanks. This looks like a bug in the logic for the noresize class not the caption itself (for the reasons I say above).
- I've opened phab:T375563 to sort that out. 🐸 Jdlrobson (talk) 21:38, 24 September 2024 (UTC)
- @Jdlrobson: the bug here is also in having
Pending changes on a module
I was asked to investigate a problem with {{convert}} at the Ukrainian Wikipedia. I have edited some pages there and am curious about the effect of a new user (me) editing a pending-changes protected page such as uk:Module:Convert/пісочниця (/sandbox). When I look at that page in a private window where I am not logged in, I can find "pername". I added that in the most recent edit which history shows as "pending review". Also, the pername change to the module is used at uk:User:Johnuniq/convert#pername (it shows dummy text "miPER" and "acrePER" in the output). In other words, an edit to the module which has not been reviewed still has an effect that is visible to all. This is not important—I'm just curious about WP:Pending changes. It appears that PC on a module does not achieve much other than flagging it as needing review? Johnuniq (talk) 02:58, 23 September 2024 (UTC)
- I think templates work the way one would expect, I would guess Scribunto content model pages just don't... Maybe @Stjn knows. Izno (talk) 03:12, 23 September 2024 (UTC)
- I just tried editing the PC protected page uk:Template:Convert/пісочниця. In a private window I could see the change to the template, and I could see the effect of the change. (I stuffed up my edit summary when I self-reverted—I meant to say that PC had no effect.) Johnuniq (talk) 03:45, 23 September 2024 (UTC)
- In Ukrainian Wikipedia, there is no expectation that pages are stabilised by default, so the page contents of /sandbox page display the unreviewed page. Template review status is tracked on pages transcluding the template that use FlaggedRevs. So User:Johnuniq/convert would also show the page with unreviewed edits while the mainspace page won’t. stjn 18:23, 24 September 2024 (UTC)
- Amazing, thanks. Johnuniq (talk) 21:20, 24 September 2024 (UTC)
- @Johnuniq Most of unreviewed changes are seen by unregistered user. It also doesn't depends if page has semi or full protection levels (however, to have fully protected page with unrewieved changes is rarest thing, because all administrator have rewiever rights). Only what matters is if a page has stabilization or not. Usually, if a page is highly proned to vandalism or have chosen as good article or featured article, administrator stabilize the page. In this case, all of unrewieved changes aren't seen by unregistered user. Usually, pages have special symbol to mark that they are stabilized, and the text on a save button would change from "save" to "write" or "write changes". Repakr (talk) 05:08, 24 September 2024 (UTC)
- Thanks. I've never seen that approach. I was wondering whether unregistered users would see the effect of an unreviewed change to a module or template. One day you might test that with a stabilized module but we have enough to think about before continuing this. Johnuniq (talk) 05:36, 24 September 2024 (UTC)
This script doesn't seem active/working anymore. Can it be fixed? Or is there an identical script? Kailash29792 (talk) 07:11, 23 September 2024 (UTC)
- I would guess this broke with the headings change earlier this year. It should be fixable, but not by me. Izno (talk) 16:00, 23 September 2024 (UTC)
- Pinging @Amorymeltzer. --Ahecht (TALK
PAGE) 16:43, 23 September 2024 (UTC) - Yeah, been bugging me too, thanks for the prompt Kailash29792. Should be working now. ~ Amory (u • t • c) 14:40, 25 September 2024 (UTC)
Tools for formatting table cells
are there any toolbar buttons or add-ins which can be used/ added for users to format cells in a table, like changing cell BG colour?
Anish Viswa 11:05, 23 September 2024 (UTC)
- No, and you should generally not want to change the background color of cells. See also WP:COLOR. Izno (talk) 16:01, 23 September 2024 (UTC)
- @Anishviswa See Template:Table cell templates/doc. --Ahecht (TALK
PAGE) 16:42, 23 September 2024 (UTC)- This is not I am looking for. Is there some option in WYSIWYG editor (add a toolbar) to select and change BG color of a cell or group of cells, like in MS Excel ?
Anish Viswa 07:54, 25 September 2024 (UTC)
- This is not I am looking for. Is there some option in WYSIWYG editor (add a toolbar) to select and change BG color of a cell or group of cells, like in MS Excel ?
Tech News: 2024-39
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
- All wikis will be read-only for a few minutes on Wednesday September 25 at 15:00 UTC. Reading the wikis will not be interrupted, but editing will be paused. These twice-yearly processes allow WMF's site reliability engineering teams to remain prepared to keep the wikis functioning even in the event of a major interruption to one of our data centers.
Updates for editors
- Editors who use the iOS Wikipedia app in Spanish, Portuguese, French, or Chinese, may see the Alt Text suggested-edit experiment after editing an article, or completing a suggested edit using "Add an image". Alt-text helps people with visual impairments to read Wikipedia articles. The team aims to learn if adding alt-text to images is a task that editors can be successful with. Please share any feedback on the discussion page.
- The Codex color palette has been updated with new and revised colors for the MediaWiki user interfaces. The most noticeable changes for editors include updates for: dark mode colors for Links and for quiet Buttons (progressive and destructive), visited Link colors for both light and dark modes, and background colors for system-messages in both light and dark modes.
- It is now possible to include clickable wikilinks and external links inside code blocks. This includes links that are used within
<syntaxhighlight>
tags and on code pages (JavaScript, CSS, Scribunto and Sanitized CSS). Uses of template syntax{{…}}
are also linked to the template page. Thanks to SD0001 for these improvements. [1] - Two bugs were fixed in the GlobalVanishRequest system by improving the logging and by removing an incorrect placeholder message. [2][3]
- View all 25 community-submitted tasks that were resolved last week.
Updates for technical contributors
- From Wikimedia Enterprise:
- The API now enables 5,000 on-demand API requests per month and twice-monthly HTML snapshots freely (gratis and libre). More information on the updates and also improvements to the software development kits (SDK) are explained on the project's blog post. While Wikimedia Enterprise APIs are designed for high-volume commercial reusers, this change enables many more community use-cases to be built on the service too.
- The Snapshot API (html dumps) have added beta Structured Contents endpoints (blog post on that) as well as released two beta datasets (English and French Wikipedia) from that endpoint to Hugging Face for public use and feedback (blog post on that). These pre-parsed data sets enable new options for researchers, developers, and data scientists to use and study the content.
In depth
- The Wikidata Query Service (WDQS) is used to get answers to questions using the Wikidata data set. As Wikidata grows, we had to make a major architectural change so that WDQS could remain performant. As part of the WDQS Graph Split project, we have new SPARQL endpoints available for serving the "scholarly" and "main" subgraphs of Wikidata. The query.wikidata.org endpoint will continue to serve the full Wikidata graph until March 2025. After this date, it will only serve the main graph. For more information, please see the announcement on Wikidata.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
MediaWiki message delivery 23:32, 23 September 2024 (UTC)
- @Quiddity (WMF) and SD0001: Regarding this change to syntaxhighlight, what would be the effect on pages like Help:Link and Help:Transclusion? Such pages have many examples of how wikitext is used, wrapped in
<syntaxhighlight lang="wikitext">...</syntaxhighlight>
where the intent is to show the markup and not the effect of using double square brackets and double braces. Will this be controllable with an attribute? If so, it should be opt-in, in order to not break all of the existing cases. --Redrose64 🌹 (talk) 06:56, 24 September 2024 (UTC)- Links are only applied within text detected by the syntax highlighter as comments (
<!-- ... -->
for lang=wikitext). The change is already live – if you don't see any effect now, there is no effect. – SD0001 (talk) 07:20, 24 September 2024 (UTC)- Example made with
<syntaxhighlight lang="wikitext">...</syntaxhighlight>
: <!-- [[Alice]] is in a wikitext comment with lang="wikitext" so it is linked. It still displays the link brackets. --> [[Boc]] is not in a comment so it is not linked. // [[Carol]] is not in a wikitext comment so it is not linked. It is in a CSS/JavaScript comment so it would have been linked with lang="CSS" or lang="JavaScript"
- PrimeHunter (talk) 11:27, 24 September 2024 (UTC)
@PrimeHunter I'm not seeing any links in that example. Is there some preference that might be overriding it? --Ahecht (TALKNever mind, refreshing the page made the link show up. Must've been a glitch. --Ahecht (TALKreply]
PAGE) 14:58, 25 September 2024 (UTC)
PAGE) 15:04, 25 September 2024 (UTC)
- Example made with
- Links are only applied within text detected by the syntax highlighter as comments (
Do we have a bot to populate a category based on the same category in another wiki?
I've just created Category:Polish archivists, which is well developed at pl:Kategoria:Polscy archiwiści. I am sure some entries from the pl category have entries here on en already. Do we have a both that could populate our category based on what is on pl? Doing this kind of stuff manually is a chore I no longer enjoy, I am afraid. Piotr Konieczny aka Prokonsul Piotrus| reply here 04:48, 24 September 2024 (UTC)
- @Piotrus I think this could be straightforward for a bot to accomplish when both categories are single level, i.e only articles, but not when there are child categogies. If there are subcategories, then it's not trivial and a bot could be disruptive. Imagine if we could add Category:Archivists from Poland (Q7604592) to an article subject, and it would populate specific language editions under certain conditions. I am holding out for wikidata improvements to address this. Ironically this convo will get archived by a bot later ;) ~ 🦝 Shushugah (he/him • talk) 11:18, 27 September 2024 (UTC)
- @Shushugah Fair point, I understand how subcategories could be messy. For now, however, a simple category copy of articles without dealing with subcategories would be much appreciated. Piotr Konieczny aka Prokonsul Piotrus| reply here 14:21, 27 September 2024 (UTC)
Mobile view center-aligns table header cells where they are left-aligned in desktop view
I'm unsure if this issue is known: I've reported it on Template_talk:Infobox_nutritional_value#Centre-aligned_labels_on_mobile_view_appear_haphazard and wondered if there should be a more general solution. Or is the different alignment intentional? Thanks, cmɢʟee⎆τaʟκ 14:43, 24 September 2024 (UTC)
- Most (if not all) browsers will centre-align table header cells by default: if left-alignment is desired, it needs to be explicitly stated. --Redrose64 🌹 (talk) 17:24, 24 September 2024 (UTC)
- Thanks, @Redrose64: What baffles me is why Desktop view left-aligns them in Template:Infobox_nutritional_value but Mobile view centre-aligns them. Any clue? cmɢʟee⎆τaʟκ 23:54, 24 September 2024 (UTC)
- I left a comment on the template talk page earlier about that. Izno (talk) 00:14, 25 September 2024 (UTC)
- For desktop view, MediaWiki:Common.css has this rule: The table header cells concerned match the first and third selectors here, so the declaration is applied to these cells. I don't think that Common.css is loaded in mobile view, so this rule is not applied. --Redrose64 🌹 (talk) 07:29, 25 September 2024 (UTC)
.infobox-label, .infobox-data, /* Remove element selector when every .infobox thing is using the standard module/templates */ .infobox th, .infobox td { /* @noflip */ text-align: left; }
- Thanks for explaining, @Izno: and @Redrose64: I'll leave it as is and await a solution then. Cheers, cmɢʟee⎆τaʟκ 19:21, 25 September 2024 (UTC)
- Thanks, @Redrose64: What baffles me is why Desktop view left-aligns them in Template:Infobox_nutritional_value but Mobile view centre-aligns them. Any clue? cmɢʟee⎆τaʟκ 23:54, 24 September 2024 (UTC)
Making this script a gadget on enwiki
I worked on this script years ago and it seems as if it has reached a mostly stable state. The script removes the "action=edit" from redlinks which essentially prevents the editor from auto-loading when clicking on non-existent pages that one has permission to create. I think this should be available as a gadget to allow for more configuration. Something like: Do not immediately enter editing mode when clicking on a red link.
Thoughts? Awesome Aasim 15:29, 24 September 2024 (UTC)
- It's hard to see why anyone would want it, even setting aside the fact it goes through every link on the page every tenth of a second. Nardog (talk) 12:45, 25 September 2024 (UTC)
- Not sure if the numbers at Wikipedia:User scripts/List are current, but if so it doesn't look like it has been picked up by many so far, so I don't expect many would opt-in. In general, we want people following a redlink to start a page. — xaosflux Talk 13:07, 25 September 2024 (UTC)
- Yeah, I am aware. This is so that it picks up links in VE previews, etc. Awesome Aasim 14:12, 25 September 2024 (UTC)
- @Awesome Aasim I haven't done much scripting around VE, but it seems like there should be a way to add an event listener to things like the VE preview window and only have it run when the content changes. --Ahecht (TALK
PAGE) 14:52, 25 September 2024 (UTC)- Hmm... I am not sure... maybe someone more experienced with scripts knows... Awesome Aasim 05:55, 26 September 2024 (UTC)
- You wouldn't even need that; you can just attach an onclick listener to "a.new" elements and modify the href to remove &action=edit as they're being clicked, even if they've been dynamically added after page load. Writ Keeper ⚇♔ 06:13, 26 September 2024 (UTC)
- Oh! Let me try this. One second. Awesome Aasim 06:13, 26 September 2024 (UTC)
- Actually, I change my mind. Doing this would cause stuff like "open link in new tab" to not function correctly. I do hope there is something smarter. Awesome Aasim 06:15, 26 September 2024 (UTC)
- No, it works with new tabs just as well as anything else: The URL modification happens before the click, so if you CTRL+click or whatever to open a new tab, it gets the modified URL. Writ Keeper ⚇♔ 06:22, 26 September 2024 (UTC)
$("#mw-content-text").on("click","a.new", function(event){ $(this).attr("href", $(this).attr("href").replace("&action=edit", "")); })
- What about links that are not in mw-content-text? For example, tabs and navbars? Awesome Aasim 06:24, 26 September 2024 (UTC)
- I'm not sure why you would have redlinks outside of mw-content-text, but if that were a concern, you'd just choose a node higher up than #mw-content-text. Writ Keeper ⚇♔ 06:25, 26 September 2024 (UTC)
- If a subject page has no talk page, the talk page tab appears as a redlink; similarly, if a talk page has no subject page, the subject page tab appears as a redlink. These tabs are outside mw-content-text. --Redrose64 🌹 (talk) 16:28, 26 September 2024 (UTC)
- I'm not sure why you would have redlinks outside of mw-content-text, but if that were a concern, you'd just choose a node higher up than #mw-content-text. Writ Keeper ⚇♔ 06:25, 26 September 2024 (UTC)
- What about links that are not in mw-content-text? For example, tabs and navbars? Awesome Aasim 06:24, 26 September 2024 (UTC)
- No, it works with new tabs just as well as anything else:
- Actually, I change my mind. Doing this would cause stuff like "open link in new tab" to not function correctly. I do hope there is something smarter. Awesome Aasim 06:15, 26 September 2024 (UTC)
- Oh! Let me try this. One second. Awesome Aasim 06:13, 26 September 2024 (UTC)
- You wouldn't even need that; you can just attach an onclick listener to "a.new" elements and modify the href to remove &action=edit as they're being clicked, even if they've been dynamically added after page load. Writ Keeper ⚇♔ 06:13, 26 September 2024 (UTC)
- Hmm... I am not sure... maybe someone more experienced with scripts knows... Awesome Aasim 05:55, 26 September 2024 (UTC)
- @Awesome Aasim I haven't done much scripting around VE, but it seems like there should be a way to add an event listener to things like the VE preview window and only have it run when the content changes. --Ahecht (TALK
- Yeah, I am aware. This is so that it picks up links in VE previews, etc. Awesome Aasim 14:12, 25 September 2024 (UTC)
I am taking a look at the requirements at WP:GADGET and it seems to meet all of them:
Gadgets must work if just included with no further configuration.
: This script requires no configuration at all.Gadgets must be compatible with all major browsers, i.e., they must not terminate with errors.
: Just checked. Works in both Chromium and Firefox based browsers.Gadgets should be functional in most major browsers (cross-browser compatibility). Exceptions must be clearly stated.
: It is. The script works on most not all browsers. It uses the URL library which is supported by practically everyone.Duplication of gadgets should only be made if it is reasonable.
: This does not apply.Collections of scripts should be split if they have disparate functions.
: This does not apply.Gadgets requiring permissions must be marked and must fail gracefully if the permissions aren't present.
: This requires no permissions at all as it only affects the behavior of red links.Gadgets only working in some skins must be marked as such if that data is available.
: Irrelevant as it works on all skins, not just Vector and Timeless.
I don't see any requirement that the script needs to see widespread usage. I am not seeking to have this turned on by default at all. Those that want it can enable it in preferences. Awesome Aasim 18:42, 29 September 2024 (UTC)
- Consider this: either it's bug reports before you turn it on or it's bug reports after. Are you planning to fix them at all? Then we just have an unmaintained gadget instead. Izno (talk) 19:31, 29 September 2024 (UTC)
- The last verified bug report I received was about interwiki links being broken by my script. That was fixed thanks to work by Matma Rex which I then implemented right after. The one after that complains that "action=delete" links are being removed, which does not sound right because this only touches red links. Not enough information was given for me to figure out where this was happening.
- There definitely is some room for optimizations, especially since having three instructions on one line is... not ideal. But those are formatting and style fixes, not functionality fixes. Awesome Aasim 19:52, 29 September 2024 (UTC)
Very small searchbox on Wikipedia:Help desk
Was the input box for Search the frequently asked questions
in the help desk always this small? It has been squished by the button so much that it can't even display one character when I start typing.
Pretty sure it happens on any setting (even mobile), but I'm using Google Chrome on a computer. – 2804:F1...F5:930E (talk)00:45, 25 September 2024 (UTC)
- That's messed up. I am able to reproduce it in Chrome. In Firefox, the search button text says "Search the freque...". I have worked around it by allowing the button to be on a second line. I wonder if something changed in the code for
<inputbox>...</inputbox>
. – Jonesey95 (talk) 00:57, 25 September 2024 (UTC)- Hmm, that's mw:Extension:InputBox? Doesn't seem like any related super recent changes there - there was an UI change in June though. I do not remember if Google Chrome ever displayed that search box correctly as I've only now paid conscious attention to it (and I don't frequent help desk, specially the top of the page, much).
- The workaround is working though, thank you. – 2804:F1...F5:930E (talk) 01:09, 25 September 2024 (UTC)
- We could up width=30 to width=40 see if that's better? Moxy🍁 01:21, 25 September 2024 (UTC)
- After testing in preview at Wikipedia:Help desk/Header/sandbox, it seems that when I restore the break=no, even if I do width=500, or 50000, nothing actually changes from width=30...
- Certainly seems like a bug. – 2804:F1...F5:930E (talk) 02:17, 25 September 2024 (UTC)
- The surrounding box is limited to 300px, so enlarging the width of the search box is probably limited by that. – Jonesey95 (talk) 02:24, 25 September 2024 (UTC)
- Well, without the break=no it does resize past the 300 (and all the way off the side of the screen), a width=3 also has no effect. They do change a size attribute in the input box, but I guess because of what Izno said below it just has no effect when the button is in the same line? – 2804:F1...F5:930E (talk) 02:47, 25 September 2024 (UTC)
- The surrounding box is limited to 300px, so enlarging the width of the search box is probably limited by that. – Jonesey95 (talk) 02:24, 25 September 2024 (UTC)
- Yes, the June update to use Codex is likely what caused the situation, if anything caused it. The block at is what causes the issue today, since it's assuming that the table width containing the whole input box is "king", more or less. And it wants to display the content from the button more than the non-content in the form input.
form.mw-inputbox-form-inline { .cdx-text-input { min-width: auto !important; } }
- (Without that CSS line at your browser, this naturally stretches the table to allow display of both the input and button. That's a feature of web tables but it causes issues in other ways sometimes.)
- Two ways to fix it probably without asking for a change upstream. One is to make the side box bigger. I wouldn't generally advise this, since that has knockon effects for use in mobile. The other is to put the input and the button on different lines. Izno (talk) 02:29, 25 September 2024 (UTC)
- We could up width=30 to width=40 see if that's better? Moxy🍁 01:21, 25 September 2024 (UTC)
Mobile view: expand all headings
Is there a gadget, user script or way to get a button to expand all headings in mobile view? It's annoying to have to manually expand them all when you want to do "find in page" or just simply want to see the whole article </MarkiPoli> <talk /><cont /> 11:44, 25 September 2024 (UTC)
- Yes, there's an option for that on Special:MobileOptions (accessible via top-left menu → Settings). [For anyone else reading this, note that the option only appears when using the mobile mode, and only on small-screen devices, since on larger devices the headings are already expanded.] Matma Rex talk 12:36, 25 September 2024 (UTC)
- Wow, never realised that! Although it doesn't seem to be a "button", just an option saying to expand all headings. That's fine, but a button would still be useful. Maybe someone could write a user script? </MarkiPoli> <talk /><cont /> 13:37, 25 September 2024 (UTC)
¬
The latest run of Special:WantedCategories features another cluster of template-autogenerated nonsense, resulting from something that was done around {{WikiProject U.S. Roads}} within the past couple of days, rating articles for the importance level of "¬". Obviously that's not a real thing we actually expect to have, and this results from a coding or spelling error somewhere, but as that template imports things from an outside module I can't find the error to fix it as it isn't in the primary template itself. So could somebody look into making the following redlinked nonsense categories go away?
- Category:¬-importance Road transport articles
- Category:¬-importance Massachusetts road transport articles
- Category:¬-importance New York road transport articles
- Category:¬-importance Pennsylvania road transport articles
- Category:¬-importance Connecticut road transport articles
- Category:¬-importance Iowa road transport articles
- Category:¬-importance Kansas road transport articles
- Category:¬-importance Maine road transport articles
- Category:¬-importance Minnesota road transport articles
- Category:¬-importance Missouri road transport articles
- Category:¬-importance New Hampshire road transport articles
- Category:¬-importance New Jersey road transport articles
- Category:¬-importance Oklahoma road transport articles
- Category:¬-importance Rhode Island road transport articles
- Category:¬-importance Texas road transport articles
- Category:¬-importance Wyoming road transport articles
- Category:¬-importance Delaware road transport articles
- Category:¬-importance Maryland road transport articles
Thanks muchly. Bearcat (talk) 18:32, 25 September 2024 (UTC)
- @Bearcat: At the moment, this isn't a VPT matter, because a group of people are presently working on WikiProject banners as a group. For instance, MSGJ (talk · contribs) has edited Template:WikiProject U.S. Roads only yesterday. You could send this somewhere like Module talk:WikiProject banner, perhaps. --Redrose64 🌹 (talk) 19:21, 25 September 2024 (UTC)
- That should be fixed now — Martin (MSGJ · talk) 21:07, 25 September 2024 (UTC)
Word count template for sections, similar to Template:Section sizes
Do we have anything that shows word count in an article by section, similar to how Template:Section sizes shows size by byte for each section? If not, wouldn't this be helpful? Bogazicili (talk) 18:37, 25 September 2024 (UTC)
Building a simple body index calculator
Having a discussion at this talk page to build a calculator using waist circumference and height as an index for body "roundness", which is based on eccentricity and used for anthropometric assessment in health research, first reported here.
A draft exists. Adjustments are needed to provide both metric and imperial inputs, and two decimal points, and any gadget assuring simplicity for public use. The completed calculator will be presented in the article. A commercial example is on this site.
Would be grateful for ideas and solutions. Thanks. Zefr (talk) 20:03, 25 September 2024 (UTC)
Bold solution: a zero input interface, no waist, no height to input, yet still provide the desired BRI: a table with waist left to right, height top to bottom, BRI in cells.
waist 1 | waist 2 | waist ... | |
---|---|---|---|
height 1 | bri w1/h1 | bri w2/h1 | ... |
height 2 | bri w1/h2 | bri w2/h2 | ... |
... | ... | ... | ... |
Uwappa (talk) 20:20, 25 September 2024 (UTC)
- Uwappa - thanks, although it isn't clear why 2 entries for waist and height are used, and the eccentricity factor is missing. Could you input data and show the result here? Also needed is the side-by-side display of metric and imperial results in 2 decimal places. See an example here (uses Wikipedia login to the medical wiki). Zefr (talk) 01:28, 26 September 2024 (UTC)
- The table was based on your "using waist circumference and height as an index for body "roundness", with waist and height being the two inputs and roundess the output.
- You will have far more than 2 entries for both waist and height, hence the three dots.
- The MDwiki asks for weight and height, not waist and height. Never mind, the idea is still the same: no input, do all computing in advance. No threshold, no effort required from readers. I've used your link to create the numbers for the example below, which will hopefully suffice to give you an idea for a similar table with waist and height as input.
- An additional idea: take it one step further and answer the question that will be in the readers mind: Am I healthy?
- Colour code the background, from green for healthy, via yellow to red for dangerous. A reader could look at the row close to own height and see multiple questions answered:
- Is my weight/waist in green, yellow or red?
- If yellow or red, what is the green value I should aim for?
- Colour codes below are not based on real data, just an example.
80 kg 90 kg ... kg 180 cm 24.7 kg/m2 27.8 kg/m2 ... 175 cm 26.1 kg/m2 29.4 kg/m2 ... ... cm ... ... ...
- An even bolder proposal that will probably rock your boat, but anyway, based on your metric/imperial question: Keep the calculator for the medics and target the general audience while on Wikipedia. Boldly omit the numbers in the cells and show both metrics and imperial in row and column headers. The table will still answer the question in the readers mind: what waist/weight is healthy for me, given my height?
80 kg 90 kg ... kg 175 lbs 200 lbs ... lbs 180 cm 6 feet 175 cm ... feet ... cm ... feet
- That might even allow to use both weight AND waist in the column headers and answer two questions: given my height, what weight and waist is healthy? — Preceding unsigned comment added by Uwappa (talk • contribs) 06:49, 26 September 2024 (UTC)
- I am reinventing the wheel. Please look at . You could do all the computations behind it and create a similar chart for BRI. Uwappa (talk) 07:24, 26 September 2024 (UTC)
- This conversation, if it is not over, should probably move to Wikipedia talk:WikiProject Medicine. It does not appear to be a technical issue. – Jonesey95 (talk) 14:18, 26 September 2024 (UTC)
- I was trying to make that photo vector, but Ive gotten bored, maybe ill finish when I get around to it Anthony2106 (talk) 13:45, 28 September 2024 (UTC)
- I've created one: cmɢʟee⎆τaʟκ 17:34, 29 September 2024 (UTC)
- This conversation, if it is not over, should probably move to Wikipedia talk:WikiProject Medicine. It does not appear to be a technical issue. – Jonesey95 (talk) 14:18, 26 September 2024 (UTC)
Why is our sister link to Kaesong on Wikivoyage starred?
On Wikivoyage, that article is just mediocre quality. There should be no start there. I am not sure how to remove it and what caused the error (could it happen for other articles?). Piotrus at Hanyang| reply here 04:20, 26 September 2024 (UTC)
- It was added to Wikidata in this revision. Not sure why as looking through the history of wikivoyage:Kaesong it was never star quality. novov talk edits 05:58, 26 September 2024 (UTC)
- @Hanyangprofessor2: The star is because of the "badge" (a little rosette) at d:Q109079#sitelinks-wikivoyage. As noted above, this was set by Dexbot (talk · contribs) almost ten years ago; you would need to ask its botop (Ladsgroup) what the mechanism is that triggered this amendment. If it really is wrong, these "badges" appear to be user-editable. --Redrose64 🌹 (talk) 15:15, 26 September 2024 (UTC)
- They aren’t; saving the changes to them is limited to certain user groups. novov talk edits 22:59, 26 September 2024 (UTC)
- @Ikan Kekek FYI, and maybe you know who to ping. Or report this to WV Traveller's Pub, I am not sure how serious this issue is, but I think the star should not be there for 'usuable' articles. Piotrus at Hanyang| reply here 07:21, 27 September 2024 (UTC)
- I don't understand the problem. It's starred on Wikidata? Best to discuss that there, I guess. I don't normally edit Wikidata. You could bring this up in the voy:Wikivoyage:Travellers' pub. Ikan Kekek (talk) 15:35, 27 September 2024 (UTC)
- @Ikan Kekek FYI, and maybe you know who to ping. Or report this to WV Traveller's Pub, I am not sure how serious this issue is, but I think the star should not be there for 'usuable' articles. Piotrus at Hanyang| reply here 07:21, 27 September 2024 (UTC)
- They aren’t; saving the changes to them is limited to certain user groups. novov talk edits 22:59, 26 September 2024 (UTC)
- @Hanyangprofessor2 The bot added the badge ten years ago because at least back then this revision to be exact had voy:Template:Usablecity. Note that the badge was added for "recommended article" [4] hence the silver (not gold). There are many badges. You should be able to see the list of page that have badges in voy:Special:PagesWithBadges Ladsgroupoverleg 10:26, 27 September 2024 (UTC)
- And the current version of voy:Kaesong#Go next still has
{{usablecity}}
. This is therefore a matter for WikiVoyage, and not our problem at all. --Redrose64 🌹 (talk) 18:06, 27 September 2024 (UTC)- @Ikan Kekek @Redrose64 The issue is that usable article on Wikivoyage are just middle-level artices (see voy:Wikivoyage:Article status). A star should denote an equivalent of a Featured article - on Wikivoyage that would be a Star-class article. A Good Article equivalent there would be a Guide (which even uses the GA green cross). Having Featured Article-lookalike barnstars for Wikivoyage usable articles, which are equivalent to our B- or C- class articles, makes no sense and is arguably actively misleading. Piotrus at Hanyang| reply here 03:16, 30 September 2024 (UTC)
- PS. And it is a problem for us (not for Wikivoyage), because it is us (English Wikipedia) that has misleading indicators suggesting that our sister project article is high quality, when it is not. Wikivoyage has correctly identified the article as a middle-level (usuable) article, but we are incorrectly starring them as high-level articles. Piotrus at Hanyang| reply here 03:18, 30 September 2024 (UTC)
- PPS. Compare to Hiroshima, which is a star-level article on Wikivoyage, and is correctly tagged with that project's yellow star in our article. Why are we tagging Wikivoyage usable articles at all, and why are we using Featured Article symbol instead of the Wikivoyage blue circle (which is the symbol for their usable articles)? At minimum, the symbol for usable content should be fixed (from FA star to blue circle), and I'd strongly suggest removing any symbols for that class (which is below GA-level equivalent). I hope the issue is now clearer? Piotrus at Hanyang| reply here 03:21, 30 September 2024 (UTC)
- And the current version of voy:Kaesong#Go next still has
Turning on the Calculator gadget as default
As a continuation of this discussion Wikipedia:Village_pump_(technical)/Archive_215#New_gadget_for_doing_user_entered_calculations, I would like to see this gadget turned on by default for pages in the Category:Pages using gadget Calculator. Any concerns? Doc James (talk · contribs · email) 18:32, 26 September 2024 (UTC)
- See this in action on an article using this special url: https://en.wikipedia.org/wiki/Body_roundness_index?withgadget=calculator — xaosflux Talk 20:01, 26 September 2024 (UTC)
- Some feedback:
- As currently written this won't work in the official Wikipedia mobile apps or for anyone with JavaScript disabled or an older browser. This needs better fallback behaviour in my opinion before being enabled. [1] FWIW viewing it without the gadget I thought the page was broken and went to edit it.
- It seems to print NaN if I enter a waist figure but no height - this seems like a basic error that should be fixed.
- Switching between metric and imperial loses the form values - this doesn't seem like a very good user experience.
- Perhaps there should be a clearer way to report bugs and some more context explaining it - that might be a case of simply adding a caption.
- Hope this is helpful.
- [1] Note that anything that uses a template gadget will not work for anyone consuming our content outside English Wikipedia so that's something to bear in mind e.g. Wikiwand, apps, Google etc.. . At minimum I think this should provide some error message saying "This interactive element is not supported by your device." 🐸 Jdlrobson (talk) 00:44, 27 September 2024 (UTC)
- Excellent points Jdlrobson. Will work on building some of these. Doc James (talk · contribs · email) 02:49, 27 September 2024 (UTC)
- Most of that is already supported by the gadget, but needed some small changes to the specific wikipage template to work. [5]. Bawolff (talk) 03:41, 27 September 2024 (UTC)
- User:Jdlrobson does this address your concerns? Doc James (talk · contribs · email) 03:49, 27 September 2024 (UTC)
- Some feedback:
- I noticed that on Firefox (version 130, x64 Linux) the width of the number inputs doesn't seem to account for the stepper arrows, causing e.g. a three-digit height (metric) on Body roundness index to be cut off on all desktop skins except Timeless. Rummskartoffel 09:14, 29 September 2024 (UTC)
- Will take a look when I have a machine I can run Firefox on... Doc James (talk · contribs · email) 14:35, 29 September 2024 (UTC)
- The fact that it differs between skins suggests to me it might be related to which font is used. Bawolff (talk) 20:31, 29 September 2024 (UTC)
- After looking more carefully, it seems like the difference is that timeless uses 15px font vs vector using 13.3px font. This adjusts the size of the input box to be different, but on firefox it appears that the number selector is a more constant size regardless of font (vs chrome where the selector only appears on hover). Bawolff (talk) 03:04, 30 September 2024 (UTC)
Weird change to mobile
For some reason, all clickable links that used to be gray have now become blue like normal links. This includes section links and the thank button, among other things. It also makes short descriptions blue when using the search feature. They are all still the correct color on the desktop version. Is this intentional, and if not, can it please be fixed? Thanks, QuicoleJR (talk) 20:46, 26 September 2024 (UTC)
- It also affects the notification when redirected to a different page, which is now hard to read because it is blue (or purple after clicked) on a black background. QuicoleJR (talk) 20:50, 26 September 2024 (UTC)
- @Jon (WMF). Izno (talk) 21:11, 26 September 2024 (UTC)
- +1 Mach61 23:56, 26 September 2024 (UTC)
- Confirming this new Thursday styling negatively affects UX legibility. Folly Mox (talk) 00:05, 27 September 2024 (UTC)
- We're aware of a few issues which seem to cover the situations you describe above:
- Let me know if there are any issues not covered by the bugs above. If so, please be specific and at minimum include URLs and description of area, and steps you followed. If you can please provide a screenshot (you can use phabricator upload if needed).
- We are looking to get these fixed next week. Jon (WMF) (talk) 00:35, 27 September 2024 (UTC)
Two separate notices when editing an old revision of an article?
Have we always had two separate notices when editing an old revision of an article? If so, why? If not, what was changed and when? ElKevbo (talk) 23:07, 26 September 2024 (UTC)
- See other pic. — xaosflux Talk 00:34, 27 September 2024 (UTC)
- The first box shows MediaWiki:Revision-info which is also shown when the revision is viewed. We have customized it. The MediaWiki default at MediaWiki:Revision-info/qqx is much shorter. The second box shows MediaWiki:Editingold. The MediaWiki default MediaWiki:Editingold/qqx is a little shorter. The defaults have no overlap in content. PrimeHunter (talk) 10:32, 27 September 2024 (UTC)
- Thanks for the quick and helpful replies! I must have seen these so many times that they don't even register with me anymore.
- The two notices do seem to be duplicative but this is not a hill I'm going to die on. Cheers! ElKevbo (talk) 14:02, 28 September 2024 (UTC)
DMCA template for templates?
There is a maintenance category Category:Wikipedia articles with colour accessibility problems containing articles that have the templates {{overcolored}} or {{overcoloured}}. The maintenance category appears to have been created by including the {{DMCA}} template in the definition of {{overcoloured}}.
However, multiple templates also have this template, for example, {{Transport in Mexico City}}. The maintenance category does not seem to include templates. (Note: I recently added the {{overcoloured}} template to that template, but have since visited Special:Purge to purge both {{Transport in Mexico City}} and Category:Wikipedia articles with colour accessibility problems. Despite this purge, {{Transport in Mexico City}} does not appear on Category:Wikipedia articles with colour accessibility problems. So it seems that {{DMCA}} is specific to articles. There also does not seem to be an existing {{DMCT}} template to allow {{overcoloured}} to create Category:Wikipedia templates with colour accessibility problems.
Is this a Phabricator feature request that I need to file? Or is there somewhere else I need to request this?
Credit to Remsense for suggesting creating the Wikipedia templates with colour accessibility problems category.
Thisisnotatest (talk) 08:27, 27 September 2024 (UTC)
- I've raised a similar situation at Template:Unreferenced. This is because the templates use Template:Ambox. Creating an exact duplicate template just so other namespaces can be categorized is a horrible idea. Instead, the system behind categorization at the base level should be changed. The template shouldn't care which namespace it is placed on for categorization. Gonnym (talk) 09:53, 27 September 2024 (UTC)
- Some categories are intended for articles only, thus {{Dated maintenance category (articles)}} (abbreviated {{DMCA}}). A category named Category:Wikipedia articles with colour accessibility problems is probably of this type. A category that can contain any kind of page would probably begin with "Wikipedia pages" instead (e.g. Category:Wikipedia pages with colour accessibility problems).There are a few variations for other cases, such as {{Dated maintenance category (files, articles, categories, and templates)}}, as well as {{Dated maintenance category}} ({{DMC}}) that doesn't do any namespace checks. The last can be used along with templates like {{Main other}}, {{Namespace detect}}, and similar templates if you need something more complex, for example if you really want Category:Wikipedia templates with colour accessibility problems, Category:Wikipedia categories with colour accessibility problems, and so on. Anomie⚔ 11:25, 27 September 2024 (UTC)
- @Anomie: Aha! So the capability already exists! So what I need to do is update the talk page of {{overcoloured}} to suggest replacing the use of {{DMCA}} with {{DMC}} or {{DMCFACT}} since I believe we would want to track all or most overcolored situations, not just those occurring on articles, and attempt to get consensus on that change to the template. Thank you! Considering this matter solved. Thisisnotatest (talk) 20:01, 27 September 2024 (UTC)
- Some categories are intended for articles only, thus {{Dated maintenance category (articles)}} (abbreviated {{DMCA}}). A category named Category:Wikipedia articles with colour accessibility problems is probably of this type. A category that can contain any kind of page would probably begin with "Wikipedia pages" instead (e.g. Category:Wikipedia pages with colour accessibility problems).There are a few variations for other cases, such as {{Dated maintenance category (files, articles, categories, and templates)}}, as well as {{Dated maintenance category}} ({{DMC}}) that doesn't do any namespace checks. The last can be used along with templates like {{Main other}}, {{Namespace detect}}, and similar templates if you need something more complex, for example if you really want Category:Wikipedia templates with colour accessibility problems, Category:Wikipedia categories with colour accessibility problems, and so on. Anomie⚔ 11:25, 27 September 2024 (UTC)
- when I saw DMCA... I was thinking what has led to people filing DMCA requests on Templates here. – robertsky (talk) 14:27, 27 September 2024 (UTC)
- @Thisisnotatest: If something is wrongly categorised, and there is a possibility that the cat is due to the effects of a template, a purge won't help because it doesn't update the link tables. A WP:NULLEDIT is the thing to try. --Redrose64 🌹 (talk) 17:23, 27 September 2024 (UTC)
'Wikidata item' link is moving. Find out where...
Hello everyone, a small change will soon be coming to the user-interface of your Wikimedia project. The Wikidata item sitelink currently found under the General section of the Tools sidebar menu will move into the In Other Projects section.
We would like the Wiki communities feedback so please let us know or ask questions on the Discussion page before we enable the change which can take place October 4 2024, circa 15:00 UTC+2.
More information can be found on the project page.
We welcome your feedback and questions.
MediaWiki message delivery (talk) 18:57, 27 September 2024 (UTC)
- @Danny Benjafield, in the future, try to avoid color, or use one of the Codex tokens directly (with a fallback). Thanks! Izno (talk) 19:59, 27 September 2024 (UTC)
Village pump permalinks?
Is there a way to provide a permalink to Village pump topics which will survive the topic being archived? Thisisnotatest (talk) 00:14, 28 September 2024 (UTC)
- Permalinks always survive archiving, as they are links to a specific revision, for example this this is the permalink to the revision prior to my response. — xaosflux Talk 00:24, 28 September 2024 (UTC)
- This question actually calls out one of the problems with organization of talk pages and any other kind of page that effectively tries to track multiple topics on a single page, particularly when they are used for the purpose of "cases" which have their own individual "lives". When you get a permalink, that lets you view the state of the page at some point in time. So if you get a permalink for such a page at some instant in time, you can see the case of interest at that point in time. You can link forward to the following version of that page, but there may have been no change to the case you're interested in. You might need to go through large numbers of versions for which the case you're interested in hasn't change. To find it just before it got migrated to an archive could have involved hundreds of versions. Of course, you can check the archive, but there could have been versions where content which was added but subsequently deleted, so you wind up having to look at numerous versions that did not affect the topic you're interested in. This is just an inherent limitation of the way that talk pages are managed. — Preceding unsigned comment added by Fabrickator (talk • contribs) 00:42, 28 September 2024 (UTC)<diff>
- Confirmed. I'm looking for a link which will always link to the current state of the topic without regard to whether the topic has been archived or had subsequent updates. Thisisnotatest (talk) 02:45, 28 September 2024 (UTC)
- @Thisisnotatest: It is presently in place, but relies on several factors. First, people must always make links to the thread using normal Wikilinks (i.e.
[[Wikipedia:Village pump (technical)#Village pump permalinks?]]
) and not external links (i.e.[https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Village_pump_permalinks%3F]
), regardless of the page where those links are made. Second, the VP page must be set up for archiving by ClueBot III (talk · contribs) (this is the case for WP:VPM and WP:VPW but not for VPI, VPP, VPR or VPT which all use lowercase sigmabot III). Third, other forms of archiving (whether manual, script or bot) must not be used on the VP page. If all of these are observed, ClueBot III will fix inward links to threads as and when they are archived, see for example these edits. --Redrose64 🌹 (talk) 10:02, 28 September 2024 (UTC)- @Redrose64: Thank you! Thisisnotatest (talk) 23:06, 28 September 2024 (UTC)
- @Thisisnotatest: It is presently in place, but relies on several factors. First, people must always make links to the thread using normal Wikilinks (i.e.
- Confirmed. I'm looking for a link which will always link to the current state of the topic without regard to whether the topic has been archived or had subsequent updates. Thisisnotatest (talk) 02:45, 28 September 2024 (UTC)
- This question actually calls out one of the problems with organization of talk pages and any other kind of page that effectively tries to track multiple topics on a single page, particularly when they are used for the purpose of "cases" which have their own individual "lives". When you get a permalink, that lets you view the state of the page at some point in time. So if you get a permalink for such a page at some instant in time, you can see the case of interest at that point in time. You can link forward to the following version of that page, but there may have been no change to the case you're interested in. You might need to go through large numbers of versions for which the case you're interested in hasn't change. To find it just before it got migrated to an archive could have involved hundreds of versions. Of course, you can check the archive, but there could have been versions where content which was added but subsequently deleted, so you wind up having to look at numerous versions that did not affect the topic you're interested in. This is just an inherent limitation of the way that talk pages are managed. — Preceding unsigned comment added by Fabrickator (talk • contribs) 00:42, 28 September 2024 (UTC)<diff>
- If you click on the timestamp for any comment, such as the first comment in a section, a link to that comment will be copied to the clipboard. When in future this section is archived, then when the link is followed, MediaWiki will display a popup message, with a link to the new location of the comment in the archive. See mw:Help:DiscussionTools § Talk pages permalinking for more details. (If you would like the link in wikitext format rather than an URL, you can try my user script to copy comment links to the clipboard to save you the work of adjusting the URL.) isaacl (talk) 05:02, 28 September 2024 (UTC)
- @Isaacl: Thank you, that's perfect, especially as I would ususally be linking to my first comment. Thisisnotatest (talk) 06:04, 28 September 2024 (UTC)
- Keep in mind, those such links are much more fragile than actual permalinks. — xaosflux Talk 09:50, 28 September 2024 (UTC)
- It's a tradeoff. A link to an actual page version won't get affected by subsequent edits, while the new talk page comment permalink feature relies on the content not being deleted without being moved, and the relevant signatures not being modified, to gain the benefit of linking to a specific comment with later responses also being shown. isaacl (talk) 17:24, 28 September 2024 (UTC)
- Keep in mind, those such links are much more fragile than actual permalinks. — xaosflux Talk 09:50, 28 September 2024 (UTC)
- @Isaacl: Thank you, that's perfect, especially as I would ususally be linking to my first comment. Thisisnotatest (talk) 06:04, 28 September 2024 (UTC)
Preview problem
Monobook, Edge, Win11. Navigation popups gadget. When I point my mouse at Jon Anderson, instead of the expected preview I see }}. DuncanHill (talk) 01:18, 28 September 2024 (UTC)
- FWIW it seems to be related to when the infobox is complicated with a module loading another box in the first infobox. Probably just beyond popups' ability to render that deep. — xaosflux Talk 10:12, 28 September 2024 (UTC)
- With
window.popupPreviewFirstParOnly = false;
in the browser console I see}}
and below it the opening paragraph. Popups apparently misreads the complicated infobox as an opening paragraph only containing}}
.{{
and}}
are correctly balanced in the article. PrimeHunter (talk) 11:56, 28 September 2024 (UTC) - Page previews tool displays the preview correctly. You may consider using that. – Ammarpad (talk) 06:54, 29 September 2024 (UTC)
Edit filter when Wikipedia is cited
Do we have an edit filter that warns people who enter Wikipedia as a citation? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:36, 28 September 2024 (UTC)
categories
What happened to the categories at the bottom of articles on the mobile version of the site? You finally added them, then they disappeared for a while, then they came back, then they disappeared for good and that was years ago. Please bring them back and keep them there, there is no reason to not have them there and it is extremely inconvenient 2603:7080:8140:8A60:14E:FF29:2359:5592 (talk) 12:42, 28 September 2024 (UTC)
- Categories are not displayed in the mobile version. Mobile users can click "Desktop" at the bottom of a page to see the desktop version with categories. Registered users can enable Advanced mode which includes a "Categories" button. PrimeHunter (talk) 13:08, 28 September 2024 (UTC)
- I added that to Help:Categories in 2021 [6] but it appears the categories are now displayed all the time in advanced mode. PrimeHunter (talk) 13:14, 28 September 2024 (UTC)
Cite This Page boilerplate
How can Special:CiteThisPage be updated? Is a Phabricator ticket required? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:50, 28 September 2024 (UTC)
- Administrators can edit MediaWiki:Citethispage-content. You can make edit requests on the talk page. PrimeHunter (talk) 13:03, 28 September 2024 (UTC)
NewUsers now blue-linking everyone’s contribs pages
iOS Safari browser: NewUsers seems to have recently had a change so that all users’ contribs pages are blue-linked, whether they’ve made an edit or not. I foresee this increasing UAA reports that get a Wait until the user edits. response. Is there a way to get around this? MM (Give me info.) (Victories) 14:45, 28 September 2024 (UTC)
- Can you be more specific about the page you are referring to? the user creation log doesn't seem to be doing this in a couple of different views I tried. — xaosflux Talk 15:05, 28 September 2024 (UTC)
- Okay, for example.
- 16:22, 28 September 2024 User account Karen8907 talk contribs was created
- ’contribs’ used to be red, if the user had made no edits. Now they are all blue, whether there’s an edit or not. Does that make more sense?
- I have ‘advanced mode’ on. Is that likely to be anything to do with it? MM (Give me info.) (Victories) 15:24, 28 September 2024 (UTC)
- When logged out, at mobile view, I only see blue contribs links; at desktop view most are red. So "advanced mode" (whatever this is) is not a factor. --Redrose64 🌹 (talk) 16:02, 28 September 2024 (UTC)
- If the user has no edits then the contribs link has the class
mw-usertoollinks-contribs-no-edits
in both desktop (tested in Vector legacy) and mobile, but only desktop has this CSS: .mw-usertoollinks-contribs-no-edits { color: #ba0000; }
- You can add the following to your CSS to get red links in all skins assuming they add the class:
.mw-usertoollinks-contribs-no-edits { color: #ba0000 !important; }
- PrimeHunter (talk) 16:36, 28 September 2024 (UTC)
- Code’s done the trick. BigThank, Prime. MM (Give me info.) (Victories) 16:57, 28 September 2024 (UTC)
- WMF recently changed link colors on Minerva and I suspect this is another casualty (or was a delta that always existed and shouldn't have). @Jon (WMF) Izno (talk) 16:48, 28 September 2024 (UTC)
- Just as a heads up, my skin is Vector (2022), not MinervaNeue. MM (Give me info.) (Victories) 16:59, 28 September 2024 (UTC)
- You linked the mobile site above and claimed to be on iOS. You cannot today select a skin for mobile website: you are always on Minerva. Izno (talk) 17:08, 28 September 2024 (UTC)
- It was xaosflux who linked mobile but MM is probably there. "Advanced mode" is a feature of the mobile version at https://en.m.wikipedia.org/wiki/Special:MobileOptions. Mobile devices usually pick the mobile version by default regardless of your skin. You can switch at "Desktop" or "Mobile view" at the bottom of pages. If it says "Desktop" then you are currently on mobile, also called Minerva. PrimeHunter (talk) 17:15, 28 September 2024 (UTC)
- You linked the mobile site above and claimed to be on iOS. You cannot today select a skin for mobile website: you are always on Minerva. Izno (talk) 17:08, 28 September 2024 (UTC)
- Yeah, they really need to fix all those new link bugs. QuicoleJR (talk) 13:23, 29 September 2024 (UTC)
- Just as a heads up, my skin is Vector (2022), not MinervaNeue. MM (Give me info.) (Victories) 16:59, 28 September 2024 (UTC)
And indeed, the CSS that should be activating is
.mw-usertoollinks-contribs-no-edits {
color: var(--color-destructive,#d73333);
}
And which is instead being overridden by
a:not([role="button"]):not(.minerva__tab-text) {
color: var(--color-progressive,#36c);
border-radius: 2px;
text-decoration: none;
}
likely due to specificity, since :not()
adds to the specificity. Izno (talk) 17:11, 28 September 2024 (UTC)
Talk pages and me not getting along
If I open a new topic on a talk (such as I have just done here) the software won't let me abandon it. It wants me to finish it. Like, suppose right now I decided "enh this isn't right venue" and left the page discarding my work (or wishing to). Well if I come back to this page tomorrow, it won't let me start a new thread, or edit an existing thread, or even read the page. Nope. It's like "You started a thread yesterday. I'll take you there now! FINISH IT AND POST IT chum and then we can talk about what I'll allow you do to next."
Mind you this is after I have clicked the "OK" on "Leave this page? Your work will be lost" box (that is generated by Firefox not Wikipedia). There it is again when I come back. I can erase the text, but can't entirely erase the title ("You can't have a blank title!") nor delete the thread. I suppose if I were to drop dead it would start harassing my estate to finish the post, I don't know.
This is no good. Can this be fixed? Is there a workaround? Fixing would better as that'd mean future editors would not have to climb the draperies. Thanks. Herostratus (talk) 17:34, 28 September 2024 (UTC)
- Click on cancel instead of emptying the contents. Sjoerd de Bruin (talk) 20:36, 28 September 2024 (UTC)
- Oof did not see that, and its right there. My bad. Sorry to bother, and thanks for the tip. Herostratus (talk) 20:52, 28 September 2024 (UTC)
Preview box
The yellow box that says This is only a preview; your changes have not yet been saved!
when you preview your edit doesn't seem to be showing up for me. Instead, the message is just shown in plain text under the "Preview" header, which makes it seem like it is part of the actual text. Was this an intentional change? The box appears normally when signed out. InfiniteNexus (talk) 18:52, 28 September 2024 (UTC)
- Works for me What is your skin and browser? --Redrose64 🌹 (talk) 20:26, 28 September 2024 (UTC)
- Vector 2010 on Chrome. But I get the same result when I try switching to Vector 2022 and Firefox. InfiniteNexus (talk) 06:46, 29 September 2024 (UTC)
Earwigs copyvio tool is down
What it says on the tin. The Earwig is aware of this. Whenever anyone tries to use the tool, they get this message most of the time: An error occurred while using the search engine (Google Error: HTTP Error 429: Too Many Requests). Note: there is a daily limit on the number of search queries the tool is allowed to make. You may repeat the check without using the search engine.
Obviously, there's a bit of tomfoolery around hitting the limit, which is apparently shared by all users of Wikipedia. There was some discussion in the WMF section of the pump a few weeks back about what the WMF can do about it. I'm mostly interested in what we can do in the meantime while it gets fixed. I dream of horses (Hoofprints) (Neigh at me) 00:56, 29 September 2024 (UTC)
- You could do your own search engine search for snippets of text from the article. One sentence from each paragraph should give an indication of problems. And you can tick the box on the tool to limit the check. Graeme Bartlett (talk) 05:49, 29 September 2024 (UTC)
- This is the message I get every time I try to use Earwig check tool since early 2024. It's always over the limit. I've asked Earwig about it multiple times and I think the problem is that bots can use it and they are causing it to hit its daily limit pretty early in the day. I wish bots could get booted of so that regular editors would have access to the tool but I have yet to see any change. I don't even try to use it any more. Liz Read! Talk! 22:43, 29 September 2024 (UTC)
- It does work for me quite often, probably as I am in a different time zone. You may have to await the end of the "day", and try again. Graeme Bartlett (talk) 22:47, 29 September 2024 (UTC)
- This is the message I get every time I try to use Earwig check tool since early 2024. It's always over the limit. I've asked Earwig about it multiple times and I think the problem is that bots can use it and they are causing it to hit its daily limit pretty early in the day. I wish bots could get booted of so that regular editors would have access to the tool but I have yet to see any change. I don't even try to use it any more. Liz Read! Talk! 22:43, 29 September 2024 (UTC)
A heading beginning with a wiki comment removes MediaWiki interface "edit" buttons for that section
Demonstrated at testwiki:Sandbox/Section edit button. Notice 2 out of 6 sections have their "edit source" or "edit" buttons missing deliberately, when a section heading text is prepended with a wiki comment (see the page source). A wiki comment after a heading on the same line works, however.
I had to make an edit Special:Diff/1248413109 here at en.wiki to workaround this MediaWiki behavior, to restore said interface button. The lack of edit interface buttons in sections can be misinterpreted confusingly as a page being protected, particularly as an unregistered user.
Is this intentional MediaWiki behavior? I didn't file or search for a bug at Phabricator, I don't have an account. 84.250.15.152 (talk) 11:26, 29 September 2024 (UTC)
- Known bad syntax MOS:SECTIONCOMMENT. Gonnym (talk) 11:41, 29 September 2024 (UTC)
Some Wayback Machine/Internet Archive links now failing?
I was doing some cleanup on Lockheed Martin shooting and came across an situation that I have never encountered before. The Internet Archive links at least on this article now seem to be failing. When I went to the saved URLs, the content that had been saved in the past came up in passing but then a different link/usurped content? for widgetbox(dot)com came up/took over. Has anyone else come across a similar issue? Is this just The Meridian Star news articles? And hey, for any of the lurkers around here who knows what's what etc, apologies in advance if I've possibly posted this issue in the wrong place, I just couldn't figure out where this might belong. No snark please, I just figured I better ask somewhere around here. - Thanks, Shearonink (talk) 18:02, 29 September 2024 (UTC)
- Shearonink, are you referring to this? — Qwerfjkltalk 19:51, 29 September 2024 (UTC)
- A couple of things happen.
- When I click though the link that you posted above I get a result saying the "page doesn't exist..."
- BUT when I click on Ref #7/"Three years later" in the Lockheed Martin shooting from the Meridian Star ->>https://web.archive.org/web/20120314014942/http://meridianstar.com/local/x681061768/Lockheed-Martin-Three-years-later?keyword=leadpicturestory I get THIS wacky "widgetserver" result-->>>https://web.archive.org/web/20120327105127/http://cdn.widgetserver.com/
- Hope i've explained it...I'm kind of flummoxed by all this. I even tried to do a search for both of the Meridian Star articles at Newspapers.com and also at the paper's website but couldn't get any results. - Shearonink (talk) 22:04, 29 September 2024 (UTC)
Related changes broken?
"Related changes" seems to be broken. I usually view CAT:RFU using RelatedChanges, like this. I'm only getting the current day's changes. This is new as of today. --jpgordon𝄢𝄆𝄐𝄇 18:12, 29 September 2024 (UTC)
- I see entries since 22 September. The top right has a box saying "500 changes, 7 days" for me. Do you have such a box, what does it say and can you change it? PrimeHunter (talk) 20:22, 29 September 2024 (UTC)
Italic title doesn't work on Mickey Maguire (Shameless), DISPLAYTITLE does
This version of Mickey Maguire (Shameless) uses {{italic title}}, and complains about no matching string. I couldn't find any invisible characters, so I'm out of ideas. Paradoctor (talk) 18:24, 29 September 2024 (UTC)
- {{italic title}} omits italics in parentheses, also when
|string=
is used. I think it should be changed but that's how it works now. {{Italic disambiguation}} can be used for your purpose without parameters. PrimeHunter (talk) 20:13, 29 September 2024 (UTC)- Alternatively, changing the page title to the more general disambiguation of "character" removes the need for italics in the title. Izno (talk) 20:28, 29 September 2024 (UTC)
- D'oh! I just realized that I should've used
|all=yes
. - Of course, {{italic disambiguation}} is easier, so I'll use that. Thanks. Paradoctor (talk) 20:45, 29 September 2024 (UTC)
Quarry down?
Hello, Tech aficianados,
I know that this area technically isn't in Wikipedia's realm of control but I was just wondering if anyone knew why Quarry was down. I can't get any of my regular pages to even load. And, unfortunately, Phab isn't accepting the password I typically use and I don't want to reset it until the end of the day so I can't file a bug report. But I did a search and I can't see that anyone else has filed a ticket either.
The message I get is a logo for Wikimedia Cloud Services and then:
- Error
- This web service cannot be reached. Please contact a maintainer of this project.
- Maintainers can find troubleshooting instructions from our documentation on Wikitech.
I tried to find a discussion page at MediaWiki but was unsuccessful. Any clues? If the cloud services are down, it seems like it would be affecting other aspects of this project but I'm just running into problems with Quarry. Thank you. Liz Read! Talk! 22:48, 29 September 2024 (UTC)
- @Taavi: could this be related to the changes from phab:T361471? – 2804:F14:80A0:C01:CAC:C72A:E92:375B (talk) 01:05, 30 September 2024 (UTC)
- Thanks for supplying this. But it's from months ago so I'm not sure if it is relevant for today's problem. Quarry gets a lot of use though so I'm surprised there isn't an open ticket. But I appreciate you looking for one that is related. Liz Read! Talk! 02:58, 30 September 2024 (UTC)
- The changes they did to fix this issue was applied on the 25th of this month, that's why I thought it might be related. At any rate Taavi is the one who made that fix, so he would know for certain - and probably can offer some information about the current problem too. – 2804:F1...92:375B (talk) 03:43, 30 September 2024 (UTC)
- I finally got the right password and filed a ticket. No response yet. Liz Read! Talk! 05:24, 30 September 2024 (UTC)
- The changes they did to fix this issue was applied on the 25th of this month, that's why I thought it might be related. At any rate Taavi is the one who made that fix, so he would know for certain - and probably can offer some information about the current problem too. – 2804:F1...92:375B (talk) 03:43, 30 September 2024 (UTC)
- Thanks for supplying this. But it's from months ago so I'm not sure if it is relevant for today's problem. Quarry gets a lot of use though so I'm surprised there isn't an open ticket. But I appreciate you looking for one that is related. Liz Read! Talk! 02:58, 30 September 2024 (UTC)