[go: nahoru, domu]
Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 77.183.18.209 (talk) at 17:19, 15 September 2024 (→Problem with account creation in Germany: Reply). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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

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.

New gadget for doing user entered calculations

We at Wiki Project Med are working to build mediawiki based calculators. One can be seen here on MDWiki mdwiki:Body_mass_index.

Within medicine there are hundreds of such calculators.[1]

Wondering about getting this functional here as a trial? More development is going to be required before this is extensively used of course.

We would need an interface admin to copy this over for it to work. Doc James (talk · contribs · email) 06:33, 4 September 2024 (UTC)[reply]

I don't see any calculator on mdwiki:Body_mass_index? – SD0001 (talk) 14:36, 4 September 2024 (UTC)[reply]
Do you see it on mdwiki:Template:Calculator#Example ? Bawolff (talk) 15:10, 4 September 2024 (UTC)[reply]
On that remote wiki I see it labeled as "BMI calculator". — xaosflux Talk 15:17, 4 September 2024 (UTC)[reply]
ah never mind, for some reason I had JS disabled on the site. – SD0001 (talk) 15:58, 4 September 2024 (UTC)[reply]
Baring any actual objections to testing I'm not seeing any showstoppers to forking over as an opt-in/?withgadget test. — xaosflux Talk 17:12, 4 September 2024 (UTC)[reply]
Thanks Xaosflux. Have built another example here mdwiki:CHA2DS2–VASc score. Once we have a testable version on EN WP will be easier to discuss with others who may be interested. Doc James (talk · contribs · email) 07:38, 5 September 2024 (UTC)[reply]
I feel like specifying formulas inline could be susceptible to subtle vandalism which would be undesirable. I'm also seeing mentions of eval, can you comment on how this calculations are being done ? (I'll note evaling user-generated content on Wikimedia sites should probably be a no-go from a security POV). Sohom (talk) 16:57, 5 September 2024 (UTC)[reply]
Everything on Wikipedia is susceptible to vandalism; it doesn't mean we stop mentioning people's birth dates and other details which can be subtly fabricated. The calculators could be made templates which can be protected if necessary. Evalling is fine if inputs are sanitised. – SD0001 (talk) 17:10, 5 September 2024 (UTC)[reply]
@SD0001 Wrt to the first point, my thought process was that manipulating birthdays would be a lesser issue than manipulating a BMI calculator that could be potentially be used by people to self-diagnose metabolism disorders. Regarding the rest, on looking further at the code, I agree that security shouldn't be a issue for it's current version, however, it would be nice to document the method the script uses anyway (as a comment) to make sure future editors of the script are aware of this consideration. Sohom (talk) 19:33, 5 September 2024 (UTC)[reply]
The tl;dr is that the formulas are parsed using a simple Recursive descent parser into an AST type structure. The AST is evaluated by walking through the tree. In the tree there are OP nodes that represent an operation from a fixed set of valid operations implemented in javascript. A dependency graph structure is also created in order to refresh any widgets that depend on a value that was changed with loop detection. Bawolff (talk) 19:41, 5 September 2024 (UTC)[reply]
I added a code comment to the script. Bawolff (talk) 19:53, 5 September 2024 (UTC)[reply]
@Sohom Datta this would serve the user some javascript, execution is client-side via browser. The script code itself could only be modified by interface admins. The current script would always be viewable by anyone, and is currently available to see at this link. — xaosflux Talk 19:30, 5 September 2024 (UTC)[reply]
The script does not use eval() as a security precaution. It is designed with security in mind. Bawolff (talk) 19:31, 5 September 2024 (UTC)[reply]
See my comment just above regarding this, I agree that is probably safe, but it would make sense to document the security considerations in the code for future interface admins/script editors. Sohom (talk) 19:36, 5 September 2024 (UTC)[reply]
I have made some enhancements to User:SDZeroBot/Gadget sync so that it also supports wikis with a non-local interwiki mapping (like mdwiki). Could be used for this. – SD0001 (talk) 08:24, 10 September 2024 (UTC)[reply]

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

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)[reply]
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)[reply]
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)[reply]
This should be fixed for this template. Izno (talk) 17:37, 5 September 2024 (UTC)[reply]

Advanced Mode issues

I have been having this issue for a while now and would like some help solving it. I use Advanced Mode as a mobile user. Occasionally, going to some pages in the Wikipedia or User namespaces will show me the non-Advanced Mode UI. Going to another page typically fixes this, and going into Settings shows that Advanced Mode is still turned on. This seems to happen most often when clicking a link from one Wikipedia namespace page to another page in that namespace, but will sometimes also happen in other circumstances. There is no visible pattern to when it happens. Does anyone know why this happens or how it can be fixed? Thanks, QuicoleJR (talk) 14:42, 6 September 2024 (UTC)[reply]

Which mobile client type (Apple, Android) and Version are you using? — xaosflux Talk 14:46, 6 September 2024 (UTC)[reply]
Using the mobile browser version on an iPhone. I'm not sure what you mean by version. QuicoleJR (talk) 14:51, 6 September 2024 (UTC)[reply]
@QuicoleJR thank you, was clarifying if you were using the browser or the Wikipedia App. For your browser, assuming you are using Safari? Are you using the current version of Safari? — xaosflux Talk 14:55, 6 September 2024 (UTC)[reply]
Actually, no, I do not use Safari. I use the Google app (not Google Chrome, Google itself). I am using the current version of Google AFAICT. QuicoleJR (talk) 15:01, 6 September 2024 (UTC)[reply]
To verify if this is some browser problem, can you try again using a different browser? — xaosflux Talk 10:09, 11 September 2024 (UTC)[reply]
Ok. I will ping you after I do that. QuicoleJR (talk) 12:05, 11 September 2024 (UTC)[reply]
@Xaosflux: I tried using Safari and encountered the same issue. It seems to be most common with FACs. QuicoleJR (talk) 12:08, 11 September 2024 (UTC)[reply]
@QuicoleJR when browsing are you logged in? Non-logged in users may get cached versions of pages. — xaosflux Talk 13:17, 11 September 2024 (UTC)[reply]
Yes, I always use Wikipedia logged-in. QuicoleJR (talk) 13:26, 11 September 2024 (UTC)[reply]
Tracked in Phabricator
Task T374311

I noticed that my userpage was in Category:Pages with image sizes containing extra px. As it turned out, this was because I had specified |widths=80px. Removing the px solved it. This appears to be a WP:PXPX issue. Checking a random sample of a dozen pages of the currently 8k+ in the category, I found that, in all cases, the member pages had the exact same issue with |widths= and/or |heights= specifications. Paradoctor (talk) 10:25, 8 September 2024 (UTC)[reply]

This is phab:T374311. I think it has always been suggested to include px in gallery sizes but now it adds the new tracking category. I think the gallery tag or tracking code should be modifed to allow one px in gallery wikitext without triggering the category, rather than mass-removing old px from all wikis to avoid the category. The suggestion to include px was removed from mw:Gallery examples yesterday and today.[2] PrimeHunter (talk) 12:49, 8 September 2024 (UTC)[reply]
This category appears to be broken at this time (false positives on properly configured gallery tags, per long-standing documentation at mediawiki.org), and possibly not needed at all, since Linter started detecting pxpx errors in 2023. I have commented at two related Phab tasks. – Jonesey95 (talk) 00:48, 10 September 2024 (UTC)[reply]
Yeah, sorry about that. Fix in gerrit, but it did uncover the fact that the 'px' suffixes weren't being localized properly on non-English wikis. C. Scott Ananian (WMF) (talk) 14:47, 11 September 2024 (UTC)[reply]
Gallery within mediawiki core itself does add an "px", so there definatly is an "pxpx" when the user gives one too. See for example https://gerrit.wikimedia.org/g/mediawiki/core/+/4d588557172511e7931bcdb63a87e9a6281c8cb3/includes/gallery/TraditionalImageGallery.php#65. That hardcoded px in code should go away, this is usually a bad practice anyway. It could also open the possibility of other units in galleries, but given that this has been hardcoded for years, it is most likely not tested at all. Snævar (talk) 14:13, 10 September 2024 (UTC)[reply]
Color me confused. When I run 
<gallery widths=180px>
foo.jpg
</gallery>
through Special:ExpandTemplates and ask it to show me the raw HTML, I see 
<div class="mw-content-ltr mw-parser-output" lang="en" dir="ltr"><ul class="gallery mw-gallery-traditional">
		<li class="gallerybox" style="width: 215px">
			<div class="thumb" style="width: 210px; height: 150px;"><span typeof="mw:File"><a href="/wiki/File:Foo.jpg" class="mw-file-description"><img src="//upload.wikimedia.org/wikipedia/commons/thumb/0/06/Foo.jpg/180px-Foo.jpg" decoding="async" width="180" height="118" class="mw-file-element" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/0/06/Foo.jpg/270px-Foo.jpg 1.5x, //upload.wikimedia.org/wikipedia/commons/0/06/Foo.jpg 2x" data-file-width="300" data-file-height="197" /></a></span></div>
			<div class="gallerytext"></div>
		</li>
</ul></div>
I don't see any pxpx in there. I agree that any hardcoded px should go away and live in the "gallery" declaration. That might allow us to use other units like em with code like "widths=10" being ambiguous. – Jonesey95 (talk) 01:31, 11 September 2024 (UTC)[reply]
gallery tags are not template-expanded to other wikitext so Special:ExpandTemplates doesn't show it but there is an internal MediaWiki process which adds px before passing code from gallery tags to other parts of MediaWiki. phab:T374311#10137524 says a patch has been uploaded today. It has to be approved and deployed but I suggest we just wait and ignore the tracking category for now. Category:Pages with image sizes containing extra px already has a note [3] about it. PrimeHunter (talk) 16:04, 11 September 2024 (UTC)[reply]

Tech News: 2024-37

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

Feature news

  • Starting this week, the standard syntax highlighter will receive new colors that make them compatible in dark mode. This is the first of many changes to come as part of a major upgrade to syntax highlighting. You can learn more about what's to come on the help page. [4][5]
  • Editors of wikis using Wikidata will now be notified of only relevant Wikidata changes in their watchlist. This is because the Lua functions entity:getSitelink() and mw.wikibase.getSitelink(qid) will have their logic unified for tracking different aspects of sitelinks to reduce junk notifications from inconsistent sitelinks tracking. [6]

Project updates

  • Users of all Wikis will have access to Wikimedia sites as read-only for a few minutes on September 25, starting at 15:00 UTC. This is a planned datacenter switchover for maintenance purposes. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [7]
  • Contributors of 11 Wikipedias, including English will have a new MOS namespace added to their Wikipedias. This improvement ensures that links beginning with MOS: (usually shortcuts to the Manual of Style) are not broken by Mooré Wikipedia (language code mos). [8]

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

MediaWiki message delivery 18:48, 9 September 2024 (UTC)[reply]

Deployment of the MOS namespace on English Wikipedia is expected to happen tomorrow. I'll post a list of titles that need to be cleaned up after it happens; expected the bare [[MOS:]] and [[MoS:]] etc to break; please replace these with WP:MOS. C. Scott Ananian (WMF) (talk) 14:52, 11 September 2024 (UTC)[reply]

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:

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}}

{{Disambig editintro}}

Anything else? Awesome Aasim 19:06, 9 September 2024 (UTC)[reply]

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

Font size change in Vector 2010

Tracked in Phabricator
Task T367643

Can anyone have a look at phab:T367643, please? I submitted this task almost four months ago. Thanks, ‑‑Neveselbert (talk · contribs · email) 22:02, 9 September 2024 (UTC)[reply]

You are running into Apple's browser's inflation algorithm which is adjusting your font size to what it thinks is the preferred minimum font size because they consider the current font-size too small for the current page and your preferences. It's best to set your preferred font size locally on your device so it doesn't change again.
You can alter this by changing your font size on your device or if you have an account applying text-size-adjust in your user CSS.
html {
  --webkit-text-size-adjust: none !important;
  text-size-adjust: none !important;
}
🐸 Jdlrobson (talk) 00:42, 10 September 2024 (UTC)[reply]
@Jdlrobson: thanks for responding. I've tried something like this already, by having JavaScript revert the viewport back to width=100 (reverting the font size back to normal). What I don't understand is why this change was applied to legacy Vector, instead of just the new Vector. ‑‑Neveselbert (talk · contribs · email) 18:59, 10 September 2024 (UTC)[reply]

I noticed some recent gallery's in articles that have this heading: <gallery mode=packed heights=250px>. The result is such a gallery having very big images, not the specified 250px but 469px high. I found the 469px by making a screenshot of the page (using Edge as browser, with zoom 100%), followed by cropping is to contain one image only. For an example see Wat Ket Karam. FredTC (talk) 11:14, 10 September 2024 (UTC)[reply]

According to dev tools they are 501x375 — Qwerfjkltalk 17:09, 10 September 2024 (UTC)[reply]
The thumbnails are shown too big, because the parameter is not "heights" but "height". "<gallery mode=packed height=250px>" works fine.--Snævar (talk) 22:30, 10 September 2024 (UTC)[reply]
No, "heights" is correct. "height" is ignored as an unknown parameter and you get a default size. I don't know the precise algorithm when heights is used but it looks like the browser may calculate how many images will fit in a row with the current window width, and then enlarges the images so the whole window width is used, except it's limited how much it will enlarge an image. And MediaWiki apparently offers a larger image file than requested with the heights parameter so the browser has a good image to work with if enlargement is needed by the algorithm. PrimeHunter (talk) 00:01, 11 September 2024 (UTC)[reply]
Then this text:
heights= Image heights in pixels (has no effect if mode is set to slideshow)
in Help:Gallery tag is incorrect. Should the help-info be modified to explain what really happens? --FredTC (talk) 10:58, 11 September 2024 (UTC)[reply]
I tried to guess what happens from some tests but I'm not comfortable writing documentation based on that. Help:Gallery tag#Usage notes says:
  • The packed mode will automatically adjust image sizes to use available display space optimally.
Help:Gallery tag#packed says: "It may relatively enlarge some images that were smaller in the above views."
The potential enlargement should maybe be mentioned when packed is introduced in Help:Gallery tag#Attributes and values. PrimeHunter (talk) 11:54, 11 September 2024 (UTC)[reply]
"Except with very good reason, a fixed width in pixels (e.g. 17px) should not be specified, because it ignores the user's base width setting." Wikipedia:Manual of Style/Images#Size Snævar (talk) 22:28, 11 September 2024 (UTC)[reply]
That doesn't apply to gallery tags. Help:Gallery tag#Usage notes says: "The default width and height are currently 120px. Images displayed by the <Gallery>...</Gallery> tag do not obey user viewing preferences." PrimeHunter (talk) 22:51, 11 September 2024 (UTC)[reply]

"Missing in" added to language selector with delay, disrupting the UI

Tracked in Phabricator
Task T344028

Hi,

Whenever I click on the language selector, it shows not only languages in which the article is available, but also suggestions of new languages to translate it in. (Which are never useful to me, but that is beside the point.)

The problem is that this suggestion appears with a delay of a second or so. See screencast:

Typically, I move my mouse cursor to the language name that I want to select, then just before I have the time to click, this suggestion appears and moves the target, so I end up clicking on the wrong languages.

Firefox 129.0 on Fedora 40. EDIT: Also reproduced with Google Chrome. Jean Abou Samra (talk) 13:02, 10 September 2024 (UTC)[reply]

This appears to be an issue with the mw:Content translation beta feature, we can not fix this directly here on the English Wikipedia. You could bring this up at the feature talk here: mw:Talk:Content translation and/or open a bug on that feature. If you open a bug, please let us know your bug id so if others come upon this discussion they can follow up on it. — xaosflux Talk 13:26, 10 September 2024 (UTC)[reply]
Done, thanks. https://phabricator.wikimedia.org/T374449 Jean Abou Samra (talk) 13:49, 10 September 2024 (UTC)[reply]
@Jean Abou Samra: If you never use the Content Translation tool then you can disable it at Special:Preferences#mw-prefsection-betafeatures. If you still want the tool enabled but never want the "Missing in [languages]" message then you can add this to your CSS:
.cx-uls-relevant-languages-banner {display:none !important;}
PrimeHunter (talk) 15:15, 10 September 2024 (UTC)[reply]
Thanks! TIL I can edit my own CSS directly in Wikipedia (rather than Greasemonkey or similar); this is going to be useful! Jean Abou Samra (talk) 19:07, 10 September 2024 (UTC)[reply]

How to mark Minor Edit on Source Editor of Mobile website

Tracked in Phabricator
Task T123694

I want to mark some of my edit as Minor Edit, but unable to do so with source editor. only Visual Editor provide interface to do that but i mostly work with source editor. how to mark any edit as minor edit on source editor of mobile website.

  • Browser: Google Chrome 128.0.6613.127

-- kemel49(connect)(contri) 15:19, 10 September 2024 (UTC)[reply]

Cannot watch or mark edit as minor with source editor on mobile website

Buttons for watching or marking an edit as minor are nonexistent on mobile website source editor.

I tested the issue on both Safari 15.6, iPadOS 15.8 on an iPad Mini 4 and on Firefox 129, Android 14 on a Samsung Galaxy S23.

Hopefully this is enough info. Treetop-64bit (talk) 23:24, 10 September 2024 (UTC)[reply]

See above section. — xaosflux Talk 10:03, 11 September 2024 (UTC)[reply]

Why can't I extract the dump?

Resolved
 – Client side issue, resolved by reporter. — xaosflux Talk 20:43, 11 September 2024 (UTC)[reply]

I tried enwiki-20240820-pages-articles.xml.bz2 and the latest enwiki dump but 7zip and bzip2 keep failing. I redownloaded it multiple times. I'm on Pop OS and there is plenty of disk space available of course.

I am using 7z x enwiki-20240820-pages-articles.xml.bz2 and

bzip2 -d enwiki-20240820-pages-articles.xml.bz2 to extract.

Error messages like ERROR: E_FAIL Archives with Errors: 1 are not very helpful. Polygnotus (talk) 22:33, 10 September 2024 (UTC)[reply]

The mailing list may be your best resource for help with that, see meta:Data dumps "Getting help" section for info. — xaosflux Talk 23:07, 10 September 2024 (UTC)[reply]

Thanks. So far I figured out that the problem is in all tools that use libbzip2 under the hood (I think 7zip and pbzip2 and bzip2). The problem is that the default block size is 900.000 bytes, and if you go over that you get: 

pbzip2 -dkv enwiki-latest-pages-articles.xml.bz2 

Parallel BZIP2 v1.1.13 [Dec 18, 2015]
By: Jeff Gilchrist [http://compression.ca]
Major contributions: Yavor Nikolov [http://javornikolov.wordpress.com]
Uses libbzip2 by Julian Seward

         # CPUs: 20
 Maximum Memory: 100 MB
 Ignore Trailing Garbage: off
-------------------------------------------
         File #: 1 of 1
     Input Name: enwiki-latest-pages-articles.xml.bz2
    Output Name: enwiki-latest-pages-articles.xml

 BWT Block Size: 900k
     Input Size: 22880311372 bytes
Decompressing data...
pbzip2: *ERROR: Could not write 900000 bytes to file [ret=-1]!  Aborting...
pbzip2: *ERROR: system call failed with errno=[2: No such file or directory]!
pbzip2: *ERROR: system call failed with errno=[5: Input/output error]!
Terminator thread: premature exit requested - quitting...
Cleanup unfinished work [Outfile: enwiki-latest-pages-articles.xml]...
Deleting output file: enwiki-latest-pages-articles.xml, if it exists...
pbzip2:  *INFO: Deletion of output file succeeded.

SO recommends some .NET lib or provides no answer.

I'll give it a try with Python before I use the mailinglist. Polygnotus (talk) 09:03, 11 September 2024 (UTC)[reply]

@Xaosflux: I figured it out: for some reason you need to sudo. sudo pbzip2 -dkv enwiki-latest-pages-articles.xml.bz2 works fine. Polygnotus (talk) 20:19, 11 September 2024 (UTC)[reply]

Notification stoppage after bot edits

Tracked in Phabricator
Task T374404

When a bot edits a watched page or file, notification emails for subsequent human edits stop being sent. Notifications only resume once the page is manually viewed or the entire watchlist is marked as read. Has anyone not had this problem? ‑‑Neveselbert (talk · contribs · email) 19:11, 10 September 2024 (UTC)[reply]

Primefac has also highlighted this problem in phab:T358087. It's still a problem, and I've missed dozens of edits because some bot edited a bunch of pages on my watchlist. ‑‑Neveselbert (talk · contribs · email) 19:15, 10 September 2024 (UTC)[reply]
See this tool and this discussion for more information. It doesn't get 100% of bot edits but it is about 99% accurate. Primefac (talk) 20:07, 10 September 2024 (UTC)[reply]
Thanks Primefac, but how do I get a "Watchlist token"? ‑‑Neveselbert (talk · contribs · email) 21:13, 10 September 2024 (UTC)[reply]
@Neveselbert: Special:Preferences#mw-prefsection-watchlist Polygnotus (talk) 21:15, 10 September 2024 (UTC)[reply]

I'm not sure if this is the right place, but why are navboxes not visible in mainspace articles in mobile view (unless rotated sideways)? They are visible in drafts. Kailash29792 (talk) 01:38, 11 September 2024 (UTC)[reply]

phab:T124168 has some background, particularly phab:T124168#1948388. Izno (talk) 01:54, 11 September 2024 (UTC)[reply]

Categories with pages that aren't in that cat

Category:NA-Class medicine articles contains a short list of pages. However, if you click on the pages in the cat, e.g., Talk:2024 United States listeriosis outbreak, there is no sign of the cat on those pages. It's been almost 8 weeks since anyone edited that talk page. How do I get this page out of that cat? WhatamIdoing (talk) 01:55, 11 September 2024 (UTC)[reply]

Make a null edit of the page. I did and it disappeared from the category. PrimeHunter (talk) 02:04, 11 September 2024 (UTC)[reply]
Thanks, that's working on most of them. WhatamIdoing (talk) 02:37, 11 September 2024 (UTC)[reply]
I can't get Help talk:Wikipedia editing for medical experts or Talk:Rorschach test/top business out of the cat. The help page would ideally be Category:Project-Class medicine articles, and the second should be an ordinary article (Category:B-Class medicine articles). I wonder whether the use of a subpage on the second one affects the template's behavior. WhatamIdoing (talk) 21:36, 11 September 2024 (UTC)[reply]
It looks like it's working as intended. The category is actually on those pages so null edits will have no effect. Help talk:Wikipedia editing for medical experts says {{WikiProject Medicine|class=Project|importance=NA}}. The WikiProject tag detects the page is not in the project talk namespace so it refuses to add Category:Project-Class medicine articles. There is no category for help pages so it's put in Category:NA-Class medicine articles instead. I would just leave it there. Talk:Rorschach test/top business serves no purpose now and should probably have been deleted or blanked after [9]. I assume the category is added because Rorschach test/top business doesn't exist. PrimeHunter (talk) 22:45, 11 September 2024 (UTC)[reply]
Thanks for the explanation. I've the templates on Rorschach page, since it's not being used. That seems to be enough. WhatamIdoing (talk) 03:57, 12 September 2024 (UTC)[reply]

Dark mode problems for code blocks

Template:Linux layers is working fine in light mode, but in dark mode, the <code>...</code> blocks (with text like "fopen") are unreadable dark gray text on dark gray background. It looks like that's happening from this CSS block: 

@media screen {
  html.skin-theme-clientpref-night table:not(.infobox):not(.navbox-inner):not(.navbox) [bgcolor] a:not(.mw-selflink), html.skin-theme-clientpref-night table:not(.infobox):not(.navbox-inner):not(.navbox) th[style*="background"]:not([style*="transparent"]):not([style*="inherit"]) a:not(.mw-selflink), html.skin-theme-clientpref-night table:not(.infobox):not(.navbox-inner):not(.navbox) td[style*="background"]:not([style*="transparent"]):not([style*="inherit"]) a:not(.mw-selflink), html.skin-theme-clientpref-night table:not(.infobox):not(.navbox-inner):not(.navbox) tr[style*="background"]:not([style*="transparent"]):not([style*="inherit"]) td a:not(.mw-selflink) {
    color: var(--color-base-fixed,#202122);

Firefox is telling me it's the last item in the comma-separated list which is active. I think this might be coming from the built-in skin CSS? This is a complicated case because the surrounding background colors are pastel in both light and dark modes, but the background of the code tag itself is white in light mode and dark gray in dark mode. It would require careful testing if this is in fact a skin problem. -- Beland (talk) 03:37, 11 September 2024 (UTC)[reply]

Yes, that's a skin issue. @Jon (WMF) Izno (talk) 03:41, 11 September 2024 (UTC)[reply]
Is this related to all HTML tags (that used to appear as green text in syntax highlighter) are now indistinguishable from plaintext when viewed in dark mode? Started yesterday on Wikivoyage, and today here on en.wiki. Zinnober9 (talk) 22:06, 12 September 2024 (UTC)[reply]
We can use TemplateStyles here to fix the local case, but links inside <code> is an unanticipated edge case. Izno (talk) 03:42, 11 September 2024 (UTC)[reply]

Unicode block template

Not sure where else to properly propose or showcase this, but I did a refactor of the Unicode block template design, introducing various BCP bells and whistles—namely dark mode support via TemplateStyles (Template:Unicode chart/styles minimal.css). Sadly, I can't use <tfoot>. Compare {{Unicode chart CJK Radicals Supplement}}

CJK Radicals Supplement[1][2]
Official Unicode Consortium code chart (PDF)
  0 1 2 3 4 5 6 7 8 9 A B C D E F
U+2E8x ⺀ ⺁ ⺂ ⺃ ⺄ ⺅ ⺆ ⺇ ⺈ ⺉ ⺊ ⺋ ⺌ ⺍ ⺎ ⺏
U+2E9x ⺐ ⺑ ⺒ ⺓ ⺔ ⺕ ⺖ ⺗ ⺘ ⺙ ⺛ ⺜ ⺝ ⺞ ⺟
U+2EAx ⺠ ⺡ ⺢ ⺣ ⺤ ⺥ ⺦ ⺧ ⺨ ⺩ ⺪ ⺫ ⺬ ⺭ ⺮ ⺯
U+2EBx ⺰ ⺱ ⺲ ⺳ ⺴ ⺵ ⺶ ⺷ ⺸ ⺹ ⺺ ⺻ ⺼ ⺽ ⺾ ⺿
U+2ECx ⻀ ⻁ ⻂ ⻃ ⻄ ⻅ ⻆ ⻇ ⻈ ⻉ ⻊ ⻋ ⻌ ⻍ ⻎ ⻏
U+2EDx ⻐ ⻑ ⻒ ⻓ ⻔ ⻕ ⻖ ⻗ ⻘ ⻙ ⻚ ⻛ ⻜ ⻝ ⻞ ⻟
U+2EEx ⻠ ⻡ ⻢ ⻣ ⻤ ⻥ ⻦ ⻧ ⻨ ⻩ ⻪ ⻫ ⻬ ⻭ ⻮ ⻯
U+2EFx ⻰ ⻱ ⻲ ⻳
Notes
1.^ As of Unicode version 16.0
2.^ Grey areas indicate non-assigned code points

with {{User:Remsense/Unicode chart CJK Radicals Supplement}}

CJK Radicals Supplement[1]
0 1 2 3 4 5 6 7 8 9 A B C D E F
U+2E8x ⺀ ⺁ ⺂ ⺃ ⺄ ⺅ ⺆ ⺇ ⺈ ⺉ ⺊ ⺋ ⺌ ⺍ ⺎ ⺏
U+2E9x ⺐ ⺑ ⺒ ⺓ ⺔ ⺕ ⺖ ⺗ ⺘ ⺙ ⺛ ⺜ ⺝ ⺞ ⺟
U+2EAx ⺠ ⺡ ⺢ ⺣ ⺤ ⺥ ⺦ ⺧ ⺨ ⺩ ⺪ ⺫ ⺬ ⺭ ⺮ ⺯
U+2EBx ⺰ ⺱ ⺲ ⺳ ⺴ ⺵ ⺶ ⺷ ⺸ ⺹ ⺺ ⺻ ⺼ ⺽ ⺾ ⺿
U+2ECx ⻀ ⻁ ⻂ ⻃ ⻄ ⻅ ⻆ ⻇ ⻈ ⻉ ⻊ ⻋ ⻌ ⻍ ⻎ ⻏
U+2EDx ⻐ ⻑ ⻒ ⻓ ⻔ ⻕ ⻖ ⻗ ⻘ ⻙ ⻚ ⻛ ⻜ ⻝ ⻞ ⻟
U+2EEx ⻠ ⻡ ⻢ ⻣ ⻤ ⻥ ⻦ ⻧ ⻨ ⻩ ⻪ ⻫ ⻬ ⻭ ⻮ ⻯
U+2EFx ⻰ ⻱ ⻲ ⻳
Unicode 16.0 – grey areas indicate non-assigned code points.

Thoughts? Remsense ‥ 论 07:51, 11 September 2024 (UTC)[reply]

@Gonnym suggested the bare EL be converted into a reference. I think I agree with that, but I didn't want to unilaterally change everything at once. It's a pretty dated design though, while several editors have tried to redesign it but haven't completed it. So, I guess I wanted to triage it and do everything right while keeping the manual work of fixing every block manageable. Remsense ‥ 论 15:37, 11 September 2024 (UTC)[reply]
A nitpick: I don't love the use of two different fonts and font sizes for the column and row headers, especially since both appear to be different from the base page font. Is there a reason for these fonts to be different from the base page font? See MOS:FONTFAMILY for a guideline. – Jonesey95 (talk) 17:09, 11 September 2024 (UTC)[reply]
Thanks for the nitpick, of course! I wouldn't do it purely for decoration per guidelines and good sense; I could easily lose one of the font sizes which was just mirroring the original, but the monospace is due to it being a computer-based code point, I guess? Now that I'm interrogating that again, it's a rather weak reason to insist on it, I think I can 86 that too. Remsense ‥ 论 17:13, 11 September 2024 (UTC)[reply]
I do think the table footer is a bit visually distracting at 1rem, especially if the string appears several times on a page corresponding to several blocks. What do you think? Remsense ‥ 论 17:19, 11 September 2024 (UTC)[reply]
Can convert it to a {{efn}} note maybe. Gonnym (talk) 17:34, 11 September 2024 (UTC)[reply]
Hmm—I think what will work is visually (but not semantically) folding it into the table like in the original. Remsense ‥ 论 17:36, 11 September 2024 (UTC)[reply]
Iterated as such. Remsense ‥ 论 17:54, 11 September 2024 (UTC)[reply]
Definitely restore the normal-sized and fixed-pitch row and column headers (you might try making *all* the characters normal-sized). Try to make the cells perfectly square and as small as possible, they seem to not be square and are bigger than before. I would just put the text "Unicode 16.0" in the header with a ref leading to the PDF, and also there is no need to tell them that gray cells are unassigned, so both footnotes are removed. Spitzak (talk) 18:22, 11 September 2024 (UTC)[reply]
I'm not sure about making square cells—which would be easy to do—of course we inspect isolated glyphs in an ideal square, but I think this becomes significantly harder to read as a table that way. Though, I realize I've picked a CJK block to test this with, maybe that's different with a graphetically different script so square cells would be best.Remsense ‥ 论 18:26, 11 September 2024 (UTC)[reply]
Hmm no, I'm full of it and square cells is obviously the move. I've allowed the headers to be bolded like in other tables instead, and I think that's good. Trying to step away so people can analyze for now. Remsense ‥ 论 18:35, 11 September 2024 (UTC)[reply]
@Remsense: You can't use tfoot for the same reason that thead and tbody (also a, img and a bunch of others) can't be used - none of these are whitelisted in MediaWiki. --Redrose64 🌹 (talk) 20:45, 11 September 2024 (UTC)[reply]
Sure, I know why! It's just a bummer in this case and a few others. Remsense ‥ 论 20:46, 11 September 2024 (UTC)[reply]
I support the rewrite, especially on accessibility grounds, but nounderlines class should probably be removed: does it even serve a purpose here? (If it even has one at al.) stjn 15:09, 12 September 2024 (UTC)[reply]
Hmm, that was another importation. I'll pull it too. Remsense ‥ 论 15:10, 12 September 2024 (UTC)[reply]
Also, thank you for the tweak—I misremembered the threshold as being 80% as opposed to 85%. Remsense ‥ 论 15:11, 12 September 2024 (UTC)[reply]
Ah, seems like it was intended to remove the underlines from symbols that get linked, e. g. Currency Symbols (Unicode block). Then it can be moved to individual <tr> blocks, I think. stjn 15:18, 12 September 2024 (UTC)[reply]
Right! Yes, I remembered then forgot that. Good catch. Remsense ‥ 论 15:19, 12 September 2024 (UTC)[reply]
nounderlines is this little bit of Common.css. Izno (talk) 15:28, 12 September 2024 (UTC)[reply]
Seems like a pretty bad relic of a different time. I get the case for why someone though this might be a good idea, but removing underlines is also just removing pretty much the only way you can tell a link from a non-link apart in Wikipedia, so moving styles like that to TemplateStyles (where they target specific things) seems much better. stjn 19:52, 12 September 2024 (UTC)[reply]
Yes, hence why it's in the TemplateStyles section of the page. The problem is that none of the classes of interest really go with specific templates, or are additionally employed in the "table" use case even when they do have a specific template in mind. So I haven't spent a ton of time trying to fix this one. Izno (talk) 20:11, 12 September 2024 (UTC)[reply]
Looking better but can you please restore the cell size to what it was in the original? We seem to be suffering some bloat, it is even larger than before. In addition the cell sizes should match the inline tables being used for 8-bit character sets, which were designed to match the original.
Though it was not in the original, making the row/col headers be fixed-pitch (as well as bold) would help for recognizing Hex values.
I still think the footer can be removed in the majority of cases. Put "Unicode 16.0" and the PDF link into the title, and just remove the "gray indicates non-assigned" as this is well known. Spitzak (talk) 17:46, 12 September 2024 (UTC)[reply]
I've reduced the effective padding, that looks better. I think I would like to maintain the table caption being used exclusively for the name of the block. I am also a hair skeptical that the meaning of gray squares is adequately intuitive to many readers who might be learning about Unicode or any related concept for the very first time, and they might not even really know that letters are assigned as such. That is to say, I think the note plausibly should remain. Remsense ‥ 论 17:56, 12 September 2024 (UTC)[reply]
I found that fixed sized boxes with a very small padding is the way to get smaller boxes. They are still too large.
For the gray, perhaps making the tooltip say "U+ABCD: unassigned" would work. Spitzak (talk) 18:16, 12 September 2024 (UTC)[reply]
That's what I've done. Are you sure they're still too large? This is the worst case scenario for readability I think, with rather complex and diverse, square-filling glyphs. I worry if I reduce the spacing any more it will become more difficult to discern one glyph from another at a glance. Remsense ‥ 论 18:18, 12 September 2024 (UTC)[reply]
Of course, then I actually try it again and decide it's fine after staring at it for a few seconds. Design is hard. Remsense ‥ 论 18:20, 12 September 2024 (UTC)[reply]
Maybe just add the PDF as a ref to the title, with no unicode version text. The Unicode version is part of the title of the reference anyway.
Yes they are still too large, as they are larger than the original. Copy however the original version set the box sizes. These glyphs should not be causing the boxes to get larger, that should not happen until the glyph literally does not fit in the box, with zero padding. Spitzak (talk) 18:19, 12 September 2024 (UTC)[reply]
Nevermind you did fix the box sizes. Looks good to me! Spitzak (talk) 18:20, 12 September 2024 (UTC)[reply]
Nevermind you did fix the box sizes. I should have taken a look. Spitzak (talk) 18:21, 12 September 2024 (UTC)[reply]
I like the fact that you fixed the width of the row headers. Do you think you could try fixed pitch? I think that will help as usually U+AB12 is being shown in a fixed-pitch font. Spitzak (talk) 18:23, 12 September 2024 (UTC)[reply]
I am on the fence about this choice as well, but I am often tugged towards parsimony (i.e. only using one font) but I'll try it out again now. Remsense ‥ 论 18:29, 12 September 2024 (UTC)[reply]
Okay, I think that's pretty perfect. Remsense ‥ 论 18:32, 12 September 2024 (UTC)[reply]
The titles are showing with serifs for me, not as U+2E8x. Spitzak (talk) 17:58, 13 September 2024 (UTC)[reply]
Actually the row titles are in a different font than the column titles. Spitzak (talk) 17:58, 13 September 2024 (UTC)[reply]
That's odd, there's no reason for that to be the case, they're both set to font-family: monospace. I'll change it though to what our templates do instead. Remsense ‥ 论 18:02, 13 September 2024 (UTC)[reply]
Oh, lookie here. I've discovered why we need a WP:MONO shortcut. Fixed. Remsense ‥ 论 18:09, 13 September 2024 (UTC)[reply]
Removing the lang="mul" from the row headers fixed it for me. Spitzak (talk) 19:52, 13 September 2024 (UTC)[reply]
Makes sense! I have no idea why they would be tagged that, as it's not the case that the text is writing several different languages! Not sure why I bothered copying it over. Remsense ‥ 论 20:20, 13 September 2024 (UTC)[reply]
I'm concerned about making the table design slicker at the expense of conveigying information clearly. That said, User:Remsense asked for my feedback on the redesign...
DRMcCreedy (talk) 20:40, 13 September 2024 (UTC)[reply]
Thank you very much, it's just what I was hoping for! Of course, the last thing I want to do is make anything less clear, but I need to do everything wrong first Remsense ‥ 论 21:35, 13 September 2024 (UTC)[reply]
The problem with nounderlines even in {{Unicode chart Mathematical Operators}} is that it affects the table caption. I wasn’t saying that nounderlines needs to be completely removed, just that it shouldn’t affect legit links unnecessarily. stjn 13:35, 15 September 2024 (UTC)[reply]
I understand now. I agree with you that links outside of the table data cell contents should have underlines. DRMcCreedy (talk) 14:56, 15 September 2024 (UTC)[reply]

References

  1. ^ "CJK Radicals Supplement" (PDF), The Unicode Standard, Version 16.0.0, South San Francisco, CA: The Unicode Consortium, 2024-09-10, pp. 325–329, ISBN 978-1-936213-34-4
Tracked in Phabricator
Task T363538

With the impending addition of MOS as a namespace on English Wikipedia, [[MOS:]] links (and [[MoS:]] etc) need to be replaced with [[WP:MOS]]. Can anyone help with that cleanup before the MOS namespace rolls out tomorrow? See T363538 and the Tech News item above for more details. C. Scott Ananian (WMF) (talk) 14:56, 11 September 2024 (UTC)[reply]

@CAnanian (WMF) wasn't the point of this supposed to be not have to touch 2000+ pages?? Why would we even want a new namespace added here otherwise?? — xaosflux Talk 15:27, 11 September 2024 (UTC)[reply]
Special:PrefixIndex/MOS:, Special:PrefixIndex/Mos:, Special:PrefixIndex/MoS:. — xaosflux Talk 15:29, 11 September 2024 (UTC)[reply]
And more specifically to not have to touch every link to these pages on every other page. — xaosflux Talk 15:29, 11 September 2024 (UTC)[reply]
The request is to fix wikilinks which only say [[MOS:]] (or other capitalizations) without anything after the colon. Those links will become broken like [[Wikipedia:]] which produces [[Wikipedia:]]. It can be fixed by replacing the links with [[WP:MOS]] which produces WP:MOS. A linksto search currently finds 4908 links to [[MOS:]] so it sounds like a job for a bot or patient AWB users. PrimeHunter (talk) 15:43, 11 September 2024 (UTC)[reply]
Thank you for the clarification. Some of these prob don't need to be done (like old talk archives). — xaosflux Talk 16:21, 11 September 2024 (UTC)[reply]
Most of them came from {{GAProgress}}, which Stjn already fixed. insource search shows 597 pages still to fix, most of which are old talk archives. * Pppery * it has begun... 16:36, 11 September 2024 (UTC)[reply]
I've also filed phab:T374555, since this concept should be supported even though it currently isn't. * Pppery * it has begun... 16:36, 11 September 2024 (UTC)[reply]
It’s still many, many pages due to that template being substituted in every GA review. So PrimeHunter’s link is better (since it captures most of the cases which are boilerplate [[MoS:|…]], and your link doesn’t). stjn 16:40, 11 September 2024 (UTC)[reply]
True. * Pppery * it has begun... 16:52, 11 September 2024 (UTC)[reply]
Old archived pages are routinely cleaned up after changes like this. Please include them in the AWB/bot work. – Jonesey95 (talk) 17:11, 11 September 2024 (UTC)[reply]
I'm in principle willing to run a bot to fix this. But I'd like to see what happens with T374555 first. * Pppery * it has begun... 17:12, 11 September 2024 (UTC)[reply]
I have just done it. I have skipped user talk pages and just a handful of sandbox pages, for which a bot may be better to avoid OBODs.
I find it telling that of the 500 some odd links, the vast majority were added because of the one template being substed or transcluded. I think maybe only some 100 uses were actual natural links, and those across the time-space of 20 years... well, I wouldn't support the work of that task. There are better edge cases to support. Izno (talk) 17:51, 11 September 2024 (UTC)[reply]
Some links start with MOS:#.[10] PrimeHunter (talk) 18:24, 11 September 2024 (UTC)[reply]
Nice catch. I've sorted these outside user talk. Izno (talk) 20:35, 11 September 2024 (UTC)[reply]
Izno, I can run this on my bot if it would help, I think this falls under WP:IAR. — Qwerfjkltalk 19:42, 11 September 2024 (UTC)[reply]
I just did it after cscott made it obvious what the impact of many of these links was (adding an iw link to mos wiki and vanishing the original link in the process). Izno (talk) 15:32, 12 September 2024 (UTC)[reply]
Script just finished running. The list of affected titles is at T363538#10141129. Most of these look fairly harmless, eg if MOS:HEAD already exists, then the existing MoS:HEAD is (a) a conflict, and so gets moved to Broken/MOS:HEAD but (b) is also unnecessary, because the namespace is case-insensitive so existing links to MoS:HEAD "just work". So the Broken/ page can be safely deleted. C. Scott Ananian (WMF) (talk) 14:47, 12 September 2024 (UTC)[reply]
It looks like Izno deleted the first set of broken pages. The second set at https://en.wikipedia.org/wiki/Special:PrefixIndex?prefix=MOS%3AT3&namespace=0 still needs to be deleted. * Pppery * it has begun... 15:17, 12 September 2024 (UTC)[reply]
And JJMC took care of another batch, including those and others like these. Izno (talk) 15:27, 12 September 2024 (UTC)[reply]

Filed a related edit request at MediaWiki talk:Title-invalid-empty. * Pppery * it has begun... 16:52, 11 September 2024 (UTC)[reply]

I've taken care of that now. Elli (talk | contribs) 15:38, 12 September 2024 (UTC)[reply]

An odd bug that for some reason only affects, ironically enough, the article VisualEditor, which is why Parsoid began in the first place.

For some reason, all citation links, which should normally cause the query fragment of the citation ID to be used as a hyperlink, for example #cite-note_24 in the Technical section, instead get #Technical, the name of a subsection, prepended to them (so something like #Technical#cite-note_24) This naturally is an invalid ID for any element on the page, and thus citations aren't able to send you to where they're stored. Despite the name, this bug appears to affect every citation on the page, as well as the caret links back.

A quick search for another article with a level 3 header as Technical was, Oura Health, did not provoke this bug.

I do apologise if this isn't the right venue for such a technical issue, but I suspect that something on VisualEditor is responsible for making Parsoid act up. Thanks for reading. Regards, User:TheDragonFire300. (Contact me | Contributions). 15:32, 11 September 2024 (UTC)[reply]

So, you mean that at https://en.wikipedia.org/wiki/VisualEditor?useparsoid=1 (link for the Parsoid version) the anchors are broken? Can confirm the described bug happens to me in that link, yes. As for the Oura Health test, I don't see a #Technical subsection in that article.
*edit: I tried with Main sequence, which does have a #Technical subsection, and the bug does not happen there. – 2804:F1...EE:9927 (talk) 19:34, 11 September 2024 (UTC) *edited 19:51, 11 September 2024 (UTC)[reply]
Something of note(maybe): The previous revision (permalink) of the VisualEditor article with Parsoid did not have broken anchors. I don't see anything in Special:Diff/1245017847 that could have caused it, though it is an edit to the #Technical subsection, hm. – 2804:F1...EE:9927 (talk) 20:15, 11 September 2024 (UTC)[reply]
I've purged the article and the links appear to be working again. -- LCU ActivelyDisinterested «@» °∆t° 20:35, 11 September 2024 (UTC)[reply]
...How did I forget about Special:Purge? Such a simple thing to fix a bizarre (?) bug. But yeah, the reason why I brought up Oura Health was that was my Special:Random-found "control group" article, to try to understand the nature of the bug. ("as Technical was" was meant to be understood in the sense that both articles had a level 3 header, not that Oura Health literally had a "Technical" subsection. But yeah, I wonder if/how this should be reported, given that the purge got rid of it. Regards, User:TheDragonFire300. (Contact me | Contributions). 23:22, 11 September 2024 (UTC)[reply]

What's the best fix for section titles containing ‹math› code?

I've come across some articles like List of repunit primes that have section titles like Bases such that is prime for prime which appear in the table of contents sidebar as Bases ?'"`UNIQ--postMath-00000001-QINU`"'? such that ?'"`UNIQ--postMath-00000002-QINU`"'? is prime for prime ?'"`UNIQ--postMath-00000003-QINU`"'. I presume this is another issue related to strip markers, but I'm not sure what the correct fix is. Should the section titles just be reworded and the <math> tags stripped out? Or is there a way to keep the math markup in the section titles without breaking the table of contents? 28bytes (talk) 22:13, 11 September 2024 (UTC)[reply]

MOS:HEADINGS says "For technical reasons, section headings should: ... Not contain <math> markup." PrimeHunter (talk) 22:22, 11 September 2024 (UTC)[reply]
Well, that sounds pretty straightforward! I'll go ahead and remove it. Thanks. 28bytes (talk) 23:00, 11 September 2024 (UTC)[reply]
I have "fixed" a few of these in the past—not really a fix because the math markup often gives a far better result in section headings. A bluesky solution might be for some new wikitext to define the heading for the contents, although that would give ugly wikitext and another hassle for visual editor developers. See this search to find more. Johnuniq (talk) 03:24, 12 September 2024 (UTC)[reply]

IP editor(s) cannot edit talk pages

Tracked in Phabricator
Task T374770

An IP editor came to my user talk, and said he was unable to edit an article talk page. So, I logged out, and tried editing article talk pages, but was also unable. What’s up? Anythingyouwant (talk) 05:04, 12 September 2024 (UTC)[reply]

What talk page can an IP not edit? What happens when they try? Johnuniq (talk) 05:31, 12 September 2024 (UTC)[reply]
When I logged out, I went to several article talk pages and couldn’t add a topic. Clicked “add topic” and nada. Anythingyouwant (talk) 05:38, 12 September 2024 (UTC)[reply]
Seeing your user talk page, the person who asked you is not an IP editor. Their described problem also happened after clicking "Add topic", which you managed to do successfully (you just hit an edit filter that prevents creating very short talk page topics as an IP or new user, the user in your user talk page did not hit that filter though).
I didn't want to finish adding a topic just to test, but I'm pretty sure I would have been able to. – 2804:F1...EE:9927 (talk) 05:32, 12 September 2024 (UTC)[reply]
He just registered, and doubtless will be able to add topics now. Anythingyouwant (talk) 05:38, 12 September 2024 (UTC)[reply]
I just logged out again and tried the “add topic” feature and it still doesn’t work. Anythingyouwant (talk) 05:41, 12 September 2024 (UTC)[reply]
Again, you are hitting an edit filter, specifically Special:AbuseFilter/1245, which, if I read the code correctly, prevents users who are not autoconfirmed or confirmed (which includes all IPs) from adding new talk page topics that have a title that is 2 words or less and a content that is 2 words or less (and less than 300 characters total).
It's there to prevent a common type of talk page spam. – 2804:F1...EE:9927 (talk) 05:45, 12 September 2024 (UTC)[reply]
Okay, it works when I add more words. Thanks. Anythingyouwant (talk) 05:52, 12 September 2024 (UTC)[reply]
I had originally tried to add the topic to Talk:Hunter_Biden_laptop_controversy without logging in. When it failed I created User:Swan2024, but I still have the same problem. I just tried again while logged in and it still fails the same way (moving slanted lines over the text for a few seconds, then gives up). I don't see any warning/error messages. I checked Special:AbuseLog and do not see any entries for me. Any other ideas? Swan2024 (talk) 00:11, 13 September 2024 (UTC)[reply]
@Swan2024: If you are trying to add external links then place them inside <nowiki>...</nowiki> in source mode to deactivate them. The add topic feature doesn't currently work with external links for users who are not autoconfirmed which requires four days and ten edits. PrimeHunter (talk) 18:28, 13 September 2024 (UTC)[reply]
Huh? Is this mentioned anywhere? That does seem to be it (can reproduce with a link to Google)...
Odd considering you can add external links just fine in replies, just have to type a captcha. – 2804:F1...A7:E311 (talk) 20:39, 13 September 2024 (UTC)[reply]
That fixed it! Thanks! Swan2024 (talk) 20:53, 13 September 2024 (UTC)[reply]

Transclusion check tool doesn't seem to work

There seems to be somethings wrond with the tool that {{check completeness of transclusions}} uses. It doesn't return an answer. HandsomeFella (talk) 22:29, 12 September 2024 (UTC)[reply]

That tool asks for bugs to be reported here. — xaosflux Talk 23:56, 12 September 2024 (UTC)[reply]

New pages highlight color changed

Until today, the "New pages" list were bright yellow highlight if no one had looked at them. It was very helpful in spotting new articles that needed editing. As of about an hour ago, that bright yellow went away and has been replaced by a very blah and light flesh colored background for the new pages. The new color, if you can even call it a color, only makes it more hard to scroll for entries. — Maile (talk) 00:25, 13 September 2024 (UTC)[reply]

You can add this to your CSS:
li.not-patrolled {background-color:yellow;}
PrimeHunter (talk) 04:29, 13 September 2024 (UTC)[reply]
Thanks. It's been years since I edited that CSS and I'm not getting it correct. — Maile (talk) 13:56, 13 September 2024 (UTC)[reply]
Just copy-paste the line to User:Maile66/common.css and ignore the warning about li.not-patrolled being overqualified. It's a yellow warning, not a red error. I added li to override the existing color declaration for not-patrolled. PrimeHunter (talk) 15:27, 13 September 2024 (UTC)[reply]
Success! Thank you! — Maile (talk) 21:43, 13 September 2024 (UTC)[reply]

Popups/tooltips editing

Who controls the tooltips, popup, etc.? Is it the developers, or can we administrators edit some MediaWiki page that controls them? I just now logged out, and I was shown a brief popup with the following text:

"You are being logged out, please wait."

This has a clear comma splice, so it needs to have the comma replaced with a semicolon, but I'm not sure how to do it or whom to ask. The popup wasn't really a separate window; it looked more like a tooltip, but it appeared only after I clicked the link, so it's not really a tooltip. Nyttend (talk) 04:49, 13 September 2024 (UTC)[reply]

The default MediaWiki message can be changed by administrators at MediaWiki:Logging-out-notify but I wouldn't create a localized message for such a small change. PrimeHunter (talk) 05:17, 13 September 2024 (UTC)[reply]
gerrit:1072652 * Pppery * it has begun... 05:33, 13 September 2024 (UTC)[reply]
Aparently @SD0001 disagrees with the semi-colon — Martin (MSGJ · talk) 10:26, 13 September 2024 (UTC)[reply]
I see the message as two sentences, so how about a full stop. Please wait is also an imperative, so perhaps it deserves an exclamation? — GhostInTheMachine talk to me 11:28, 13 September 2024 (UTC)[reply]
A full stop would work fine as well. I don't think an exclamation mark is needed (I can't tell if the above is humor). – Jonesey95 (talk) 12:03, 13 September 2024 (UTC)[reply]
Only semi-serious on the pling. Can go with or without. Perhaps we need a {{not serious}} or {{inline humour}} template? — GhostInTheMachine talk to me 12:49, 13 September 2024 (UTC)[reply]
We have an entire collection of such templates. – SD0001 (talk) 07:30, 14 September 2024 (UTC)[reply]

Not receiving "Reset Password" emails

I've submitted my information to the "Reset Password" form, but I am not receiving the "Reset Your Password" email(s). I've submitted:

• Both username and email • Username only • Email only

I have access to the email account, and my last login with my username was 2018.

How can I reset my password? 2001:5A8:49C4:BC00:90B:103A:2BA0:38B0 (talk) 21:10, 13 September 2024 (UTC)[reply]

Accounts and passwords never expire. If you have a spam folder, maybe at your email provider, then try checking it. If you post the username (on this public page which already shows your IP address) then we can check whether the account exists and has an email address stored, but that's all. We cannot see what the email address is. If you didn't store one or cannot receive mail at it then you have to create new account. PrimeHunter (talk) 21:41, 13 September 2024 (UTC)[reply]
Thank you, I've been checking my spam folders, but I'm not getting an email.
Username is Emdub510 2001:5A8:49C4:BC00:90B:103A:2BA0:38B0 (talk) 22:02, 13 September 2024 (UTC)[reply]
The account User:Emdub510 does exist and has set an email address but has chosen to not receive mails from other users. The account was created in 2006. Most users rarely or never use our email features so it's plausible you gave the email address in 2006 and never needed it before now. Maybe you changed email address? The account has made 119 edits (only 1 since 2011). That's low by Wikipedia standards. You can just create a new account. If you want you can write on the user page of the old and new account that you are the same user. PrimeHunter (talk) 23:28, 13 September 2024 (UTC)[reply]
For privacy reasons, somebody who isn't logged in to the account cannot test at Special:PasswordReset or elsewhere whether it has a specific email address. PrimeHunter (talk) 23:32, 13 September 2024 (UTC)[reply]
Your best course of action might be to file a bug report in Phabricator about not receiving the password reset emails for your account. The developers can both look into that and offer any alternatives. Anomie⚔ 13:34, 14 September 2024 (UTC)[reply]

Problem with account creation in Germany

I'm unable to create an account, because I always get the message "Visitors to Wikipedia using your IP address have created 6 accounts in the last 24 hours..." It seems like something is broken. I asked about it a few days ago at the Help Desk: Wikipedia:Help desk/Archives/2024 September 10#Unable to create account - a few admins looked at it, but couldn't help.

My Mac computer has a dynamic IP on O2/Telefonica in Germany. It changes once a day usually, or if I power-cycle my router. I've tried about 20 different IP numbers, over the past week, and it's always the same. I've tried several different browsers, emptying my cache, and creating a fresh browser profile in Firefox. It's also happening on my phone. I've tried using my phone's browser on WiFi. Then I turned off WiFi, and used the phone's cellular data, which is also on O2/Telefonica, but mobile. I tried using the phone as a mobile hotspot for my computer. But it's always the same error message, no matter what I do.

It seems unlikely that every single address has been used to create multiple Wikipedia accounts in the past day. Like there would have to be some kind of bot net cycling through IP numbers and creating thousands of accounts. Otherwise, because the number doesn't change that often, it feels like something is malfunctioning, and that it's not my equipment. If so, it may be affecting a large number of people, since this is a major ISP and this address pool covers a large part of Germany, including Berlin. I understand I could try to use the "request an account" page, but I wanted to report this as possibly a bug. Any ideas, or someone else I should talk to? Thanks. 77.183.18.209 (talk) 15:17, 15 September 2024 (UTC)[reply]

@77.183.18.209 You can request an account via this page. A volunteer will review your request shortly after it is submitted. NightWolf1223 <Howl at me•My hunts> 15:25, 15 September 2024 (UTC)[reply]
Thanks, I understand I can request an account that way, but I prefer not to give my real e-mail address (even if it's not retained), and it says that I can't use a throw-away address. So it's a little inconvenient. But the main thing is that this seems like a bug that should be reported and fixed, if it's affecting more than just me. 77.183.18.209 (talk) 15:37, 15 September 2024 (UTC)[reply]
There may be a more legitimate reason as to why your IPv4 address hits the 6-account creation limit: your service provider may be using a CGNAT setup in which the same IPv4 address is potentially shared across hundreds of their subscribers. How to determine you are on CGNAT, check your modem/router WAN IP address, and see if it matches your public address (which you can check with a third party website such as https://whatismyipaddress.com/). If indeed it is a CGNAT setup, you can only registere through WP:ACC or access Wikipedia on another ISP that does not use CGNAT or see if you can force an IPv6-only connection on your current provider (not sure if this will work through). – robertsky (talk) 15:38, 15 September 2024 (UTC)[reply]
@Robertsky: Thanks for the info. I don't think that's the case though. If I log into my router's admin interface, the WAN address listed is the same as the public IP address reported by whatismyipaddress.com. The IPv6 number is blank in the router, and not listed on whatismyipaddress.com. But if I use my phone as a mobile hotspot, with cellular data (which I'm doing right now), I do get an IPv6 number. But I just tried again, and I still get the "more than 6 accounts" message. 2A02:3032:312:C23E:651B:88A4:497B:5E99 (talk) 16:01, 15 September 2024 (UTC)[reply]
Back on DSL again - according to o2 customer service CGNAT is not used on my DSL line. I also did a traceroute on my WAN IP, and there's only one hop. 77.183.18.209 (talk) 17:19, 15 September 2024 (UTC)[reply]

The Interface

About how text is displayed:

  • As for the Italic text feature in English, it is towards the right. But this happens even for the Arabic language, and this is considered a Wrong.
  • There is another matter, I see that the level of spacing between the lines along the article page is too far apart from each other.

Mohmad Abdul sahib talk☎ talk 16:48, 15 September 2024 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1245876284"