Wikipedia:Village pump (technical)
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.
|
New gadget for doing user entered calculations
[edit]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)
- I don't see any calculator on mdwiki:Body_mass_index? – SD0001 (talk) 14:36, 4 September 2024 (UTC)
- Do you see it on mdwiki:Template:Calculator#Example ? Bawolff (talk) 15:10, 4 September 2024 (UTC)
- On that remote wiki I see it labeled as "BMI calculator". — xaosflux Talk 15:17, 4 September 2024 (UTC)
- ah never mind, for some reason I had JS disabled on the site. – SD0001 (talk) 15:58, 4 September 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
- @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)
- 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)- I added a code comment to the script. Bawolff (talk) 19:53, 5 September 2024 (UTC)
- 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
- @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)
- @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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Not seeing any blockers to testing, will work on import/setup. — xaosflux Talk 14:54, 11 September 2024 (UTC)
Dark mode when logged out of Wikipedia
[edit]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)
Navigation icons have vanished
[edit]Using Firefox and Dark Reader with Light Mode on, the icons are the same hue as the background and are not visible.
Fix by using Wikipedia's new Dark Mode? Not so fast. The background is too dark and the text is too bright. My eyes hurt when looking at it, and they don't hurt when using Dark Reader. This issue has already been raised by multiple users,[2] and will no doubt be solved in a timely fashion. But until then it would be nice to hit the undo button on whatever happened this week to the icons.
Here is some color data:
Wikipedia dark mode - harsh contrast
icons 234 236 240 Luminosity: 93%
back 16 20 24 Luminosity: 8%
Dark reader - easy on the eyes
text 232 230 227 Luminosity: 90%
back 24 26 27 Luminosity: 10%
This broke only a few days ago. Before, the icons were mostly correct except for the drop-down arrows. Wizmut (talk) 02:56, 6 September 2024 (UTC)
- Possibly phab:T374180 which is now fixed. 🐸 Jdlrobson (talk) 00:31, 10 September 2024 (UTC)
- Still broken. Is there a better place to report this issue? Wizmut (talk) 00:49, 10 September 2024 (UTC)
Technical Powers to "Block"
[edit]As my account has now been "blocked" - I began to ponder, peacefully - if Wikipedia has a forum of experts who deliberate as a technical team to "block or not" or is it an individual who decides and activates a "block" on a fellow wikipedian? I will patiently await a response or redirect to an article addressing my concerns. ZAWADI NPC (talk) 07:57, 6 September 2024 (UTC)
- See WP:BLOCK for more information about the blocking process. 331dot (talk) 08:26, 6 September 2024 (UTC)
- Your account is not blocked, ZAWADI NPC (as evidenced by your ability to post here). Why do you think it is? It has never been blocked. Bishonen | tålk 08:31, 6 September 2024 (UTC).
- Their user page was deleted, maybe they think that is a block? 331dot (talk) 08:34, 6 September 2024 (UTC)
- You were advertising on your page. Advertising is not allowed on Wikipedia, not even on your page. You don't own that page – it is only there to show people what kind of Wikipedia editor you are, not anything about your business. You may say something about hobbies or interests that you don't get money from, for example if you take great photographs and put them on Wikipedia (for free of course), then you can say so. TooManyFingers (talk) 19:23, 7 September 2024 (UTC)
Advanced Mode issues
[edit]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)
- Which mobile client type (Apple, Android) and Version are you using? — xaosflux Talk 14:46, 6 September 2024 (UTC)
- 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)- @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)
- 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)
- To verify if this is some browser problem, can you try again using a different browser? — xaosflux Talk 10:09, 11 September 2024 (UTC)
- Ok. I will ping you after I do that. QuicoleJR (talk) 12:05, 11 September 2024 (UTC)
- @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)
- @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)
- Yes, I always use Wikipedia logged-in. QuicoleJR (talk) 13:26, 11 September 2024 (UTC)
- @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)
- To verify if this is some browser problem, can you try again using a different browser? — xaosflux Talk 10:09, 11 September 2024 (UTC)
- 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)
- @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)
- Using the mobile browser version on an iPhone. I'm not sure what you mean by
templatedata not showing up
[edit]i have added templatedata to Template:Infobox card game. why isn't it showing up when editing, say, whist? ltbdl☃ (talk) 08:58, 7 September 2024 (UTC)
- That's weird. Izno (talk) 16:23, 7 September 2024 (UTC)
- Works for me. I null-edited the Infobox template. Editing the /doc template should, in a perfect world, immediately provide a null edit to the single page that transcludes it, but it rarely does so. – Jonesey95 (talk) 22:25, 7 September 2024 (UTC)
- I was able to reproduce earlier in Firefox up to date, but no longer. Maybe indeed it was a question of needing a null edit. Izno (talk) 22:39, 7 September 2024 (UTC)
- Works for me. I null-edited the Infobox template. Editing the /doc template should, in a perfect world, immediately provide a null edit to the single page that transcludes it, but it rarely does so. – Jonesey95 (talk) 22:25, 7 September 2024 (UTC)
No search box for default skin
[edit]The search box at the top of the main page en.wikipedia.org is absent on the default skin, at least on certain browsers. There is an empty area where it would belong, but there's nothing visible or clickable there. This happens at least on some versions of Chrome. The default skin on mobile is still working fine. On desktop, switching skins fixes the problem. Could this be dark mode related? TooManyFingers (talk) 16:39, 7 September 2024 (UTC)
- I found my problem.
- 1. Clicking the magnifying glass icon is now required, to use the search box.
- 2. My magnifying glass is not visible in dark mode. But it's there and I can click on it. TooManyFingers (talk) 17:19, 7 September 2024 (UTC)
- Clicking the icon should be required only at smaller resolutions. But it should still be visible, so something there is weird. Izno (talk) 18:39, 7 September 2024 (UTC)
- Another user who's not on dark mode says the magnifying glass is invisible or barely visible for them too. So it's not just dark mode. TooManyFingers (talk) 19:07, 7 September 2024 (UTC)
- Several similar complaints at WP:Help desk recently. Gråbergs Gråa Sång (talk) 09:30, 8 September 2024 (UTC)
- Another user who's not on dark mode says the magnifying glass is invisible or barely visible for them too. So it's not just dark mode. TooManyFingers (talk) 19:07, 7 September 2024 (UTC)
- Clicking the icon should be required only at smaller resolutions. But it should still be visible, so something there is weird. Izno (talk) 18:39, 7 September 2024 (UTC)
Current date templates break after entering source editor
[edit]The default template for dating tags Template:Currentyear and Template:Currentmonth turn into a nowiki format after entering and exiting source. Roasted (talk) 00:52, 8 September 2024 (UTC)
- Aren't they supposed to do that? They mean "today as I am writing", not "today as someone is reading 30 years later" ... TooManyFingers (talk) 06:19, 8 September 2024 (UTC)
- @Roastedbeanz1: Your post could refer to different situations. Describe what you did from the start, what you expected and what happened instead. Save and link an edit where it happened. If you tried to add templates using source code like
{{...}}
} in VisualEditor then it's not supposed to work. VisualEditor has its own way of adding templates. See Help:VisualEditor#Editing templates. PrimeHunter (talk) 09:20, 8 September 2024 (UTC)
- @Roastedbeanz1: Your post could refer to different situations. Describe what you did from the start, what you expected and what happened instead. Save and link an edit where it happened. If you tried to add templates using source code like
PXPX issue with GALLERY tag
[edit]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)
- 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 oldpx
from all wikis to avoid the category. The suggestion to includepx
was removed from mw:Gallery examples yesterday and today.[3] PrimeHunter (talk) 12:49, 8 September 2024 (UTC)- 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)
- 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)
- 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)
- Color me confused. When I run through Special:ExpandTemplates and ask it to show me the raw HTML, I see
<gallery widths=180px> foo.jpg </gallery>
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)<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>
- 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 [4] about it. PrimeHunter (talk) 16:04, 11 September 2024 (UTC)
- 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
- Color me confused. When I run
Auto-expand "Learn more about this page" on navigation to anchor
[edit]This is with reference to the trouble a user reported at Talk:Turkey#Extended-confirmed-protected edit request on 12 August 2024 and similar reports I've seen elsewhere. In mobile view, the tags at the top of a talk page are hidden under an expandable link reading "Learn more about this page". These tags may include, among other things, a FAQ tag. When, in a discussion on the page, we want to route an inquiring editor to the FAQ (such as to Talk:Turkey#FAQ), we can't do so for a mobile user because the link doesn't work and the user, even if they scroll to the top (which is now the second thing they've tried in their attempt to see the referenced material), don't see the FAQ and don't see the third thing, clicking "Learn more about this page" that they'd have to do to get there, or perhaps at that point they've already given up.
Is it possible through some feat of CSS and/or Javascript wizardry to cause the top material to expand automatically upon navigation to an anchor that's within it? Largoplazo (talk) 17:31, 8 September 2024 (UTC)
Why isn't this valid CSS?
[edit]The problem I'm having is actually on wikiconference.org, not here, but I'm asking this here because this is where all the really smart people hang out :-)
I'm trying to generate some custom CSS for https://wikiconference.org/wiki/2024/Schedule which will let me highlight the talks I want to go to. this works, but only highlights the talk title. this one highlights every table cell (as expected). this one does exactly what I want (i.e. highlights the table cell containing the desired title), but when I go to save it, I get an error message "The document contains errors. Are you sure you want to save?" and "Error: Expected RPAREN at line 1, col 9". Ignoring the error message and clicking "OK" seems to work fine.
Is this really invalid CSS, or is the editor just giving me a bogus warning? RoySmith (talk) 14:06, 9 September 2024 (UTC)
- The editor is older than the CSS you're employing. Izno (talk) 15:54, 9 September 2024 (UTC)
- Thanks. As far as I can tell, :has() was introduced in 2018, but I guess that's not a long time by wiki standards. RoySmith (talk) 16:31, 9 September 2024 (UTC)
:has()
was first-implemented in 2022 by Safari, then Chromium, then late 2023 by Firefox (implementing it was non-trivial for performance reasons), and I think went through a few name changes between 2018 and 2022. I am not surprised that the editor doesn't know it. Izno (talk) 16:41, 9 September 2024 (UTC)- @RoySmith: The W3C doc that you link is a Working Draft, which is a long way from being a Recommendation. The
:has()
pseudo-class is not part of the Selectors Level 3 spec, which is a W3C Recommendation. --Redrose64 🌹 (talk) 19:00, 9 September 2024 (UTC)- Thank you. RoySmith (talk) 19:43, 9 September 2024 (UTC)
- Thanks. As far as I can tell, :has() was introduced in 2018, but I guess that's not a long time by wiki standards. RoySmith (talk) 16:31, 9 September 2024 (UTC)
Special:Preferences sticky table header hides first data row
[edit]Originally reported in Phabricator but closed as "invalid" because "this is a local gadget". https://phabricator.wikimedia.org/T374327
Basically, enabling "Make headers of tables display as long as the table is in view" in Special:Preferences Gadgets results in the first table data row in templated tables being hidden by the table header rows shifted down. See Phabricator ticket for example and screenshots. ~Anachronist (talk) 14:19, 9 September 2024 (UTC)
- Interestingly, it displays properly in Chrome if my window is about half the width of the screen, or if I turn on Developer Tools so that the display area is about half the width of the screen. --SarekOfVulcan (talk) 14:28, 9 September 2024 (UTC)
- Your Phabricator example is Template:Series overview/doc. That template has code which works poorly with the gadget. See MediaWiki talk:Gadget-StickyTableHeaders.css#Not working at The Economist Democracy Index#List by region. PrimeHunter (talk) 18:03, 9 September 2024 (UTC)
- I had noticed it in other places, but I got bothered enough yesterday to report it after my most recent occurrence, which happened to be the series overview template. It also happens to every table in Historical rankings of presidents of the United States, for example. ~Anachronist (talk) 20:21, 9 September 2024 (UTC)
Tech News: 2024-37
[edit]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. [5][6]
- 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()
andmw.wikibase.getSitelink(qid)
will have their logic unified for tracking different aspects of sitelinks to reduce junk notifications from inconsistent sitelinks tracking. [7]
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. [8]
- Contributors of 11 Wikipedias, including English will have a new
MOS
namespace added to their Wikipedias. This improvement ensures that links beginning withMOS:
(usually shortcuts to the Manual of Style) are not broken by Mooré Wikipedia (language codemos
). [9]
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)
- 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)
Enhanced editnotice loader
[edit]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)
Font size change in Vector 2010
[edit]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)
- 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.
- 🐸 Jdlrobson (talk) 00:42, 10 September 2024 (UTC)
html { --webkit-text-size-adjust: none !important; text-size-adjust: none !important; }
- @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)
Gallery issue
[edit]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)
- According to dev tools they are 501x375 — Qwerfjkltalk 17:09, 10 September 2024 (UTC)
- 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)
- 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)
- 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)
- 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.
- The
- 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)
- 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:
- "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)
- 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)
- 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
- Then this text:
- 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)
"Missing in" added to language selector with delay, disrupting the UI
[edit]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)
- 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)
- Done, thanks. https://phabricator.wikimedia.org/T374449 Jean Abou Samra (talk) 13:49, 10 September 2024 (UTC)
- @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)
- 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)
- Done, thanks. https://phabricator.wikimedia.org/T374449 Jean Abou Samra (talk) 13:49, 10 September 2024 (UTC)
How to mark Minor Edit on Source Editor of Mobile website
[edit]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)
- This feature is not currently available in the mobile web view, see phab:T123694. As a workaround you could change to the desktop view. — xaosflux Talk 15:41, 10 September 2024 (UTC)
- @Xaosflux@KEmel49 we have also fielded a couple wishes on this. There might be an update regarding the availability of this feature.
- Out of curiosity, how would you feel if all editors saw this UX? JWheeler-WMF (talk) 19:03, 10 September 2024 (UTC)
- I'd be fine, as they do in VE mode already - think it should at least be consistent. — xaosflux Talk 21:47, 10 September 2024 (UTC)
- @JWheeler-WMF: As someone who uses the mobile source editor, I would appreciate the change. I don't think it makes sense to keep it from only one type of editor. QuicoleJR (talk) 12:12, 11 September 2024 (UTC)
- As we note any Minor copy edit as CE at Edit summary field, can't we note any minor edit as
<m>
or with any other tag,that cannot be marked on checkbox for technical limitation.-- kemel49(connect)(contri) 15:28, 11 September 2024 (UTC)
Cannot watch or mark edit as minor with source editor on mobile website
[edit]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)
- See above section. — xaosflux Talk 10:03, 11 September 2024 (UTC)
Why can't I extract the dump?
[edit]![](http://upload.wikimedia.org/wikipedia/en/thumb/f/fb/Yes_check.svg/20px-Yes_check.svg.png)
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)
- 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)
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)
@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)
Notification stoppage after bot edits
[edit]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)
- 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)
- 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)
- Thanks Primefac, but how do I get a "Watchlist token"? ‑‑Neveselbert (talk · contribs · email) 21:13, 10 September 2024 (UTC)
- 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)
Navboxes in mobile view
[edit]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)
- phab:T124168 has some background, particularly phab:T124168#1948388. Izno (talk) 01:54, 11 September 2024 (UTC)
Categories with pages that aren't in that cat
[edit]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)
- Make a null edit of the page. I did and it disappeared from the category. PrimeHunter (talk) 02:04, 11 September 2024 (UTC)
- Thanks, that's working on most of them. WhatamIdoing (talk) 02:37, 11 September 2024 (UTC)
- 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)
- 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 [10]. I assume the category is added because Rorschach test/top business doesn't exist. PrimeHunter (talk) 22:45, 11 September 2024 (UTC)- 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)
- 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
- 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)
- Thanks, that's working on most of them. WhatamIdoing (talk) 02:37, 11 September 2024 (UTC)
Dark mode problems for code blocks
[edit]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)
- Yes, that's a skin issue. @Jon (WMF) Izno (talk) 03:41, 11 September 2024 (UTC)
- 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)
Unicode block template
[edit]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 |
with {{User:Remsense/Unicode chart CJK Radicals Supplement}}
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 | ⻰ | ⻱ | ⻲ | ⻳ |
Thoughts? Remsense ‥ 论 07:51, 11 September 2024 (UTC)
- @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)
- 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)
- 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)
- 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)- Can convert it to a {{efn}} note maybe. Gonnym (talk) 17:34, 11 September 2024 (UTC)
- 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)
- Iterated as such. Remsense ‥ 论 17:54, 11 September 2024 (UTC)
- 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)
- Can convert it to a {{efn}} note maybe. Gonnym (talk) 17:34, 11 September 2024 (UTC)
- 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)
- 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)
- 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)
- 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)
- @Remsense: You can't use
tfoot
for the same reason thatthead
andtbody
(alsoa
,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)- Sure, I know why! It's just a bummer in this case and a few others. Remsense ‥ 论 20:46, 11 September 2024 (UTC)
- @Remsense: You can't use
- 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)
- 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)
- 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)- Hmm, that was another importation. I'll pull it too. Remsense ‥ 论 15:10, 12 September 2024 (UTC)
- Also, thank you for the tweak—I misremembered the threshold as being 80% as opposed to 85%. Remsense ‥ 论 15:11, 12 September 2024 (UTC)
- 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)- Right! Yes, I remembered then forgot that. Good catch. Remsense ‥ 论 15:19, 12 September 2024 (UTC)
nounderlines
is this little bit of Common.css. Izno (talk) 15:28, 12 September 2024 (UTC)- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Nevermind you did fix the box sizes. Looks good to me! Spitzak (talk) 18:20, 12 September 2024 (UTC)
- Nevermind you did fix the box sizes. I should have taken a look. Spitzak (talk) 18:21, 12 September 2024 (UTC)
- 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)
- 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)
- Okay, I think that's pretty perfect. Remsense ‥ 论 18:32, 12 September 2024 (UTC)
- 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)
- 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)
- 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)
References
- ^ "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
Cleaning up MOS: links
[edit]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)
- @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)
- Special:PrefixIndex/MOS:, Special:PrefixIndex/Mos:, Special:PrefixIndex/MoS:. — xaosflux Talk 15:29, 11 September 2024 (UTC)
- 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)
- 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)- 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)
- 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)
- 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)
- 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)- True. * Pppery * it has begun... 16:52, 11 September 2024 (UTC)
- 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)
- 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)
- 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)
- Some links start with
MOS:#
.[11] PrimeHunter (talk) 18:24, 11 September 2024 (UTC)- Nice catch. I've sorted these outside user talk. Izno (talk) 20:35, 11 September 2024 (UTC)
- 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)
- 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)
- Some links start with
- 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)
- 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)
- True. * Pppery * it has begun... 16:52, 11 September 2024 (UTC)
- 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)
- 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)
- The request is to fix wikilinks which only say
- 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)
- 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)
- And JJMC took care of another batch, including those and others like these. Izno (talk) 15:27, 12 September 2024 (UTC)
- 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)
Filed a related edit request at MediaWiki talk:Title-invalid-empty. * Pppery * it has begun... 16:52, 11 September 2024 (UTC)
- I've taken care of that now. Elli (talk | contribs) 15:38, 12 September 2024 (UTC)
Cite links are broken when VisualEditor is rendered in Parsoid
[edit]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)
- 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)
- 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)
- I've purged the article and the links appear to be working again. -- LCU ActivelyDisinterested «@» °∆t° 20:35, 11 September 2024 (UTC)
- ...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)
- ...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. (
- I've purged the article and the links appear to be working again. -- LCU ActivelyDisinterested «@» °∆t° 20:35, 11 September 2024 (UTC)
- 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)
What's the best fix for section titles containing ‹math› code?
[edit]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)
- MOS:HEADINGS says "For technical reasons, section headings should: ... Not contain <math> markup." PrimeHunter (talk) 22:22, 11 September 2024 (UTC)
- Well, that sounds pretty straightforward! I'll go ahead and remove it. Thanks. 28bytes (talk) 23:00, 11 September 2024 (UTC)
- 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)
- Well, that sounds pretty straightforward! I'll go ahead and remove it. Thanks. 28bytes (talk) 23:00, 11 September 2024 (UTC)
IP editor(s) cannot edit talk pages
[edit]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)
- What talk page can an IP not edit? What happens when they try? Johnuniq (talk) 05:31, 12 September 2024 (UTC)
- 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)
- 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)
- He just registered, and doubtless will be able to add topics now. Anythingyouwant (talk) 05:38, 12 September 2024 (UTC)
- 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)
- 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)
- Okay, it works when I add more words. Thanks. Anythingyouwant (talk) 05:52, 12 September 2024 (UTC)
- 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)
- He just registered, and doubtless will be able to add topics now. Anythingyouwant (talk) 05:38, 12 September 2024 (UTC)