Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Jdlrobson (talk | contribs) at 00:07, 24 September 2024 (→table-caption minerva issue: 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.

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]

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]

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]
I'm going to judge the EL vs. reflist citation position as no consensus for the moment, meaning I'll try a version with the existing convention as well. Further thoughts on each?
Unicode 16.0[2] – grey areas indicate non-assigned code points.
Unicode 16.0 (official chart) – grey areas indicate non-assigned code points.
Remsense ‥ 论 03:18, 16 September 2024 (UTC)[reply]
I strongly prefer the EL with the PDF symbol because it's much more obvious there's a PDF chart available. Especially nice if it's a block I don't have fonts installed for. DRMcCreedy (talk) 14:48, 18 September 2024 (UTC)[reply]
The lang="mul" reappeared for some reason Spitzak (talk) 04:23, 16 September 2024 (UTC)[reply]
It's a citation. EL should not be placed in the middle of articles per WP:NOELBODY. How does this usage satisfy "rare exception"? Gonnym (talk) 15:16, 18 September 2024 (UTC)[reply]
I'm so used to the current format that this never occurred to me. I guess that pushes us towards a normal citation. That said, I'd like the citation chapter parm changed to "Code chart for xxx" (where xxx is the block name) and the page number parm removed (because of the maintenance issues with new releases). DRMcCreedy (talk) 16:02, 18 September 2024 (UTC)[reply]
I'm happy to make any future changes if consensus agrees to them or problems are indicated; for the moment, is everyone okay with me starting to implement this new design, possibly as a handful of metatemplates, that can replace the existing unicode block templates? Also, third option: just put the citation template itself in the bar?
"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 – grey areas indicate non-assigned code points.
Remsense ‥ 论 22:00, 18 September 2024 (UTC)[reply]
That is probably the worst option. Just make it a citation, there is no reason to prefer an inline icon for the link in the footer. stjn 16:58, 19 September 2024 (UTC)[reply]
I only worry that it'll cause heartburn for those working with the bespoke citation styles existing in maybe 2–10 articles ever, but whatever at this point. Remsense ‥ 论 17:01, 19 September 2024 (UTC)[reply]
Yes I think it should be a plain old citation in the header. The header could look like this:
CJK Radicals Supplement Unicode 16.0 [3]
I do think the link to the PDF has to be in the title somehow. Spitzak (talk) 17:43, 19 September 2024 (UTC)[reply]
@Drmccreedy @Spitzak @Stjn @Gonnym how's that, y'all? —you know what, I won't apologize for including the full citation template. hurts no one!Remsense ‥ 论 20:02, 19 September 2024 (UTC)[reply]
Hard no on using the full citation in the header. I think that is still an inline citation so if breaks the MOS. I'm fine with just a reference so long as the title is "Code chart for ..." or "Official Code Chart for ...". DRMcCreedy (talk) 21:44, 19 September 2024 (UTC)[reply]
I dropped the inline cite idea. Remsense ‥ 论 21:58, 19 September 2024 (UTC)[reply]
Current version looks good to me Spitzak (talk) 22:59, 19 September 2024 (UTC)[reply]
I notice the page numbers are still on the reference. I'd like to reiterate that these are a maintenance issue and not useful to the reader because they will just pull up the PDF, not look up the page numbers is some hardcopy or omnibus PDF. DRMcCreedy (talk) 14:33, 20 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
  2. ^ "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
  3. ^ This is the citation to the PDF

Thoughts on Docbunto?

I encountered a powerful autodoc tool on Fandom Dev Wiki called Docbunto, and I have been able to get some changes to make it work on Test Wikipedia. I think it would be very great to have an autodoc tool like Docbunto on Wikipedia to help speed up the process of writing module documentation. But the key feature I like is the ability to transclude templates and similar on Lua pages.

I don't think it is ready for English Wikipedia yet but maybe with a few changes it can be very feature rich and ready. Yeah we are not exactly a code repository, but we do have thousands of modules used across articles that would be helpful to have auto documentation for. Awesome Aasim 18:21, 17 September 2024 (UTC)[reply]

Wiktionary uses something similar. See wikt:Module:module documentation.
But the key feature I like is the ability to transclude templates and similar on Lua pages. As for this, we can already do this on this wiki: Module:Module wikitext. – SD0001 (talk) 20:15, 17 September 2024 (UTC)[reply]
Another improvement we can do over wiktionary is take advantage of line numbers now being linkable. Ideally, the generated docs of exported functions should include links to their source code definitions. – SD0001 (talk) 20:18, 17 September 2024 (UTC)[reply]
As for this, we can already do this on this wiki: Module:Module wikitext. That is very bodgy, and it doesn't entirely make sense to me how this works or why this should work. But then, an autodoc module rendering module comments is also very bodgy, although less bodgy because reading out comments to parse from the module is less likely to break than reading out variables from the documentation module after setting them in "addText". Module comments should be taken advantage of in the parser. I did open a task (and submit my first patch to MediaWiki to complete it) for having MediaWiki only parse the contents of CSS and JS comments, see phab:T373834 (and kindly do please send more feedback on how I can improve that patch!) Awesome Aasim 00:21, 18 September 2024 (UTC)[reply]
We considered generating documentation from LuaDoc when creating Scribunto, but we decided not to for the same reasons most documentation pages here are on /doc subpages instead of being inline in the template page: inlined docs can't be protected separately from the module/template and any edit to inlined docs means any pages using the module/template have to be reparsed. Anomie⚔ 23:50, 17 September 2024 (UTC)[reply]
I'd figure. I think of this inline doc as a good starting point for most Lua modules but ultimately there should be additional documentation that goes beyond the default functions and describes what the module exactly does. Awesome Aasim 23:53, 17 September 2024 (UTC)[reply]
Yeah, being able to edit documentation without going through edit requests would be nice, even though so would be autogenerating doc sections for functions. Nardog (talk) 01:20, 18 September 2024 (UTC)[reply]
Automated cat herding is not going to work at Wikipedia. Imagine forcing every module to have comments in a fixed format with extra gunk to be machine parsable. Johnuniq (talk) 02:27, 18 September 2024 (UTC)[reply]
It is really bad practice to not put comments in code. Autodoc obviously won't work if there aren't any properly formatted comments. The goal of autodoc is to document functions and variables and more importantly module exports. Even functions in use by other modules. It never is intended to replace the module documentation page at the top of each; just supplement it. Awesome Aasim 03:05, 18 September 2024 (UTC)[reply]
Yes, useful comments are great. What I meant was, it would be very difficult to get independent editors to use a fixed format. Also, I don't think documenting all functions and variables is achievable or even desirable, for example, due to the inevitable drift between hopeful comments and actual code. I do agree that exports should be documented and I once argued strongly that a module (I forget where now) should not have every function exported due to ensuing confusion and maintenance issues. I lost that argument. Johnuniq (talk) 03:34, 18 September 2024 (UTC)[reply]
There is a few related stuff I can think of.
Automatically making a list of variables is actually easy. The hard part is getting arguments in loops. See is:Module:Templatedata fyrir skriftu, which can create basic templatedata (containing only a list of variables) with the code {{#invoke:Templatedata fyrir skriftu|main|''name of module with namespace''}}.
There is also an request to WMF at meta:Community_Wishlist/Wishes/Document_ALL_the_modules! about this same subject.
Come to think of it some of doc.wikimedia.org is actually built on similar logic to docbunto. Snævar (talk) 19:08, 19 September 2024 (UTC)[reply]
Why not both? If there's comments in code formatted in a certain way, show them in /doc, but also allow overriding or appending to it without having to edit the module directly. Nardog (talk) 03:37, 18 September 2024 (UTC)[reply]
+1. I do think having both is useful. We can provide an end user overview at the top of the module documentation page, and a developer's overview in the autodoc. Something similar to how I implemented autodoc on testwiki:Module:Docbunto and testwiki:Module:i18n. There should be some sort of disclaimer that the documentation is auto generated and the contents can be overridden. Awesome Aasim 14:42, 18 September 2024 (UTC)[reply]

Sort irregularity

At List of Women's Basketball Academic All-America Team Members of the Year the header sort is not working for the Aliyah Boston rows.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 12:14, 18 September 2024 (UTC)[reply]

Resolved
-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 03:11, 19 September 2024 (UTC)[reply]

table-caption minerva issue

On screens below width 640px there are two related issues with table captions in Drummully#Statistics on mobile, ie https://en.m.wikipedia.org/wiki/Drummully#Statistics.

  • In both tables, the caption only spans the first column.
  • In the first table, the caption is below the column headers.

The cause is the user agent's default display ... 

caption {
   display: table-caption;


... is overridden by a Minerva stylesheet 

@media screen and (min-width: 640px) {
   .content caption {
       display: block

When I comment out that line in my Browser developer settings, both tables look fine.

The CSS file's URL is

here

I dunno where the corresponding source is, or whether this is a Wikipedia or MediaWiki issue, or if there is a defect logged and/or a workaround available. jnestorius(talk) 16:05, 18 September 2024 (UTC)[reply]

The caption being set to display block has always been weird to me; the other display blocks in Minerva make some sense (but I also think I've played around with this before and come to the conclusion that it was necessary?? memory is weird on this point).
skins.minerva.base.styles/content/tables.less is the source. Izno (talk) 16:32, 18 September 2024 (UTC)[reply]
Captions should be either display:table-caption; or display:none;. Nothing else is sensible. --Redrose64 🌹 (talk) 19:39, 18 September 2024 (UTC)[reply]
TLDR: The issue is the inline style adding display: inline-table which is interfering with Minerva's ability to make the table responsive on a mobile device. Please move this to a TemplateStyle so that it only applies at a suitable breakpoint and does not break the display on mobile.
Longer version: On mobile, since a table doesn't fit in the screen, presenting them to mobile devices becomes tricky. The way we approach this general in MediaWiki sites, it to convert the display property of all table elements to block-based layouts rather than table-based layouts. Applying display block to the table caption, will ensure that it does not require horizontal scrolling to be viewed and will span multiple lines if needed. While this might seem strange is a pretty widely recommended and sensible practice.
The bug here IMO is not the table caption - it's the use of display inline-table. If you load this article on a mobile device, and expand sections you'll see that this introduces horizontal scroll on the page e.g. the table breaks the content of the whole article. e.g. the whole article is not mobile friendly (note the whitespace to right of chrome in this screenshot: https://phabricator.wikimedia.org/F57532981).
Inline styles as always interfere with a lot of the logic we have to optimize content. As with dark mode where use of any kind of color can break dark mode display - using display or width or height properties interfere with the responsive behaviour and I would personally recommend always using mw:TemplateStyles to express these. 🐸 Jdlrobson (talk) 00:07, 24 September 2024 (UTC)[reply]

Extra spaces at start of article

Fame (Confederate monument). I succeeded in removing them but I'm certain that what I removed to accomplish this should not be removed.— Vchimpanzee • talk • contributions • 21:24, 18 September 2024 (UTC)[reply]

They shouldn't be removed, no. Swapping their order fixed the whitespace, as did moving {{italic title}} below the infobox; moving {{short description}} below it instead did not. It's not immediately clear why. —Cryptic 21:57, 18 September 2024 (UTC)[reply]
Thanks, and is there somewhere we can document this in case someone finds the same problem elsewhere?— Vchimpanzee • talk • contributions • 23:13, 18 September 2024 (UTC)[reply]
Something to do with templates that produce no output. Perhaps phab:T369520? The cure, apparently, is to add a leading <nowiki /> tag. Why? Don't know.
—Trappist the monk (talk) 23:23, 18 September 2024 (UTC)[reply]
If a template has no output then a call of the template placed on its own line becomes a blank line, causing whitespace. If the template returns a nowiki then MediaWiki doesn't treat it as a blank line. PrimeHunter (talk) 00:13, 19 September 2024 (UTC)[reply]
The current (better) workaround, in case anyone else looks at the article's history, just sees the reverts, and is confused. {{short description}} already had something similar for blank shortdescs; and non-blank ones do have output, a div that's hidden by css. —Cryptic 01:20, 19 September 2024 (UTC)[reply]

Specific Dumps

Hi, I would like a dump for the following: All Featured articles, All featured lists, All good articles, and all Vital Articles (All levels). Preferrably in separate files for each of the requests. And also preferably in html, pdf, or a similar format. I don’t like the xml one due to it having the coding and unnecessary stuff included. Is this possible? I was told to come here after asking on Help Desk. Thanks, MrM MiniMikeRM (talk) 12:47, 19 September 2024 (UTC)[reply]

MiniMikeRM, you could try something like Special:Export + Category:Featured articles. You won't be able to get anything other than XML. Other than that, you'd need to download the full dump and filter it. The only way to get the HTML dumps (that I know of) is https://dumps.wikimedia.org/other/enterprise_html/. — Qwerfjkltalk 18:33, 19 September 2024 (UTC)[reply]
Thanks, how would I go about filtering though? MiniMikeRM (talk) 11:55, 20 September 2024 (UTC)[reply]
MiniMikeRM, it depends on what you're using. You could use an XML parser, iterate through the pages, and check the categories or whatever else you want to check. — Qwerfjkltalk 18:16, 22 September 2024 (UTC)[reply]

Test for presence of Newcomer home page

Is there an #if test I can do on some variable, or an #ifexist <file> to check if a user has their newcomer home page enabled? I wish to provide a link at H:YFA to the newcomer home page (Special:Homepage), but only if they have one. A magic word {{HOMEPAGE}} that returns non-empty would be nice, but anything that works is good.

Note: if you are an experienced user reading this, that Special link probably goes nowhere for you, as it did for me, until I enabled it in the bottom section at Preferences. If you've never seen the Homepage, it's interesting, and if you are a WP:Tea house aficionado, it may help you help others. Mathglot (talk) 19:27, 19 September 2024 (UTC)[reply]

No, there is not. Izno (talk) 19:53, 19 September 2024 (UTC)[reply]
Darn; okay, thanks. Mathglot (talk) 20:32, 19 September 2024 (UTC)[reply]
Two points of context to know more about the user case you envision, @Mathglot:
  • Since August 2022, all newcomers have access to the homepage.
  • Some (more experienced) users opted-out the homepage in their preferences, but they know that.
Could we say these two points are a enough to consider that the number of newcomers who would have a "no access" message is low enough to add the link to H:YFA? Trizek_(WMF) (talk) 10:48, 20 September 2024 (UTC)[reply]
Trizek_(WMF}, thanks for this. You echo my musings about this, as I have been thinking about adding it anyway, and assumed that all new users have the page, and that at least some older users don't, either because like me, they predate the feature, or that other editors have opted out on the Preferences page (or maybe aged out automatically after X-hundred or-thousand edits or whatever). So, I was coming around to your view, and hearing these details cinches it; I will add the link. Thanks for jumping in.
P.S. You might consider adding a WP:DOPPELGANGER account for Trizek (WMF), which is how I automatically spelled your name while typing, to prevent any future mischief. Most WMF users use blank there, not underscore as I recall, so it's a familiar pattern. Thanks, Mathglot (talk) 17:46, 20 September 2024 (UTC)[reply]
Crap, can't win for losing; you already had it that way, and the underscore is added as a custom sig? You really know how to confuse a bod... . @Trizek (WMF):. Mathglot (talk) 17:49, 20 September 2024 (UTC)[reply]
Ha, sorry for the confusion regarding the underscore @Mathglot! It is the opposite effect I was looking for: I added it to my signature as a global setting for RTL languages. It is also for other users who miss the parenthesis: they are quite regularly pinging my volunteer account... ;) Trizek_(WMF) (talk) 12:32, 23 September 2024 (UTC)[reply]
 Done. Trizek, I've gone ahead and made that change; thanks. Mathglot (talk) 21:53, 22 September 2024 (UTC)[reply]

Issue with Template:Inflation

Not sure if this is just on my end, but when I open the template page, I get the message "The time allocated for running scripts has expired.". I've searched through the archives but I have no clue how to check the Lua runtime and don't even know if if it needs to be fixed or if this'll just go away, but just thought I'd make the pump aware. Sincerely, Dilettante 20:20, 19 September 2024 (UTC)[reply]

It's affecting several articles too, Oscar Wilde and Pouakai Range are full of error messages and missing templates. Kindlejim (talk) 20:37, 19 September 2024 (UTC)[reply]
I found the error at Caltech. Sincerely, Dilettante 20:45, 19 September 2024 (UTC)[reply]
Yes, I see it too. 'Find' and 'sub' callbacks take 9 seconds:
Parser profiling data of Template:Inflation:
Parser profiling data (help):

CPU time usage	10.868 seconds
Real time usage	11.235 seconds
Preprocessor visited node count	17,969/1,000,000
Post-expand include size	304,975/2,097,152 bytes
Template argument size	55,123/2,097,152 bytes
Highest expansion depth	29/100
Expensive parser function count	12/500
Unstrip recursion depth	0/20
Unstrip post-expand size	6,600/5,000,000 bytes
Lua time usage	10.069/10.000 seconds
Lua memory usage	25,050,261/52,428,800 bytes
Lua Profile
MediaWiki\Extension\Scribunto\Engines\LuaSandbox\LuaSandboxCallback::find		5140 ms	49.6%
MediaWiki\Extension\Scribunto\Engines\LuaSandbox\LuaSandboxCallback::sub		4020 ms	38.8%
?		440 ms	4.2%
MediaWiki\Extension\Scribunto\Engines\LuaSandbox\LuaSandboxCallback::match		240 ms	2.3%
MediaWiki\Extension\Scribunto\Engines\LuaSandbox\LuaSandboxCallback::getExpandedArgument		100 ms	1.0%
recursiveClone	<mwInit.lua:45>	80 ms	0.8%
dataWrapper	<mw.lua:672>	80 ms	0.8%
MediaWiki\Extension\Scribunto\Engines\LuaSandbox\LuaSandboxCallback::gsub		60 ms	0.6%
MediaWiki\Extension\Scribunto\Engines\LuaSandbox\LuaSandboxCallback::callParserFunction		60 ms	0.6%
MediaWiki\Extension\Scribunto\Engines\LuaSandbox\LuaSandboxCallback::getContent		60 ms	0.6%
[others]		80 ms	0.8%
Number of Wikibase entities loaded	0/400
Maybe someone with better tech chops can help you. Mathglot (talk) 20:41, 19 September 2024 (UTC)[reply]
Presumably caused by this good-faith edit which I've since reverted. Izno (talk) 21:32, 19 September 2024 (UTC)[reply]
@Dilettante, Kindlejim, Mathglot, Izno: Oops, my bad. I implemented an automatic version of {{Inflation/year}} that uses Lua, but it turns out mw.text.split() is incredibly slow. Replacing it with a home-grown splitting function made it 20x faster. I've fixed the Lua module and re-implemented it, and it's now working with all the above pages (except Pouakai Range, which appears to be an unrelated issue with {{Maplink}}). --Ahecht (TALK
PAGE) 00:06, 20 September 2024 (UTC)[reply]
Ahecht, Thanks. It sounds like something wildly beyond normal expectation, especially since your home-brew version was so much faster. I don't know Lua yet, but mw.text.split() looks like it might be some imported library routine defined externally somewhere. If that's close to right, would you mind commenting/filing a Phabricator ticket or whatever the right response is about that routine, wherever it happens to be? Mathglot (talk) 00:19, 20 September 2024 (UTC)[reply]
@Mathglot It seems to be a known issue (see phab:T278206). The reason mine is faster is that the built-in one is Unicode aware and mine is not. --Ahecht (TALK
PAGE) 00:56, 20 September 2024 (UTC)[reply]
Thanks; I reopened it. Mathglot (talk) 03:23, 20 September 2024 (UTC)[reply]
@Ahecht:, closed again; see this comment. Do you think you can create a new ticket for this? You are much more plugged in to what is going on here than I am, and I fear my explanation would not be complete or accurate. Thanks, Mathglot (talk) 11:19, 21 September 2024 (UTC)[reply]
@Mathglot I really don't know too much about the issue other than what is in that ticket, and I fear that a regression that occurred 3 years ago may be hard to track down. --Ahecht (TALK
PAGE) 22:58, 21 September 2024 (UTC)[reply]

"The time allocated for running scripts has expired"

In the process of doing some category cleanup today, I came across Albert Bridge, London, a page which looks fine at first, but about halfway down once you get to the "structural weaknesses" section, becomes absolutely swarmed with a constant profusion of blaring red "The time allocated for running scripts has expired" error messages every time there's supposed to be a footnote. The last time I saw something like this, it was because the affected page had recently been moved, so there was a conflict between its title and the title that was being expected by various templates, but that doesn't seem to be the case here as the page hasn't been moved at all. So could somebody take a look at this and figure out how to fix whatever's wrong? Thanks. Bearcat (talk) 20:47, 19 September 2024 (UTC)[reply]

For the moment I've removed the dynamic content (Special:Diff/1246585381) that was trying to display the current year and the problem went away - at least the page is readable now, this needs more investigation. — xaosflux Talk 21:17, 19 September 2024 (UTC)[reply]

Inflation Template may be broken

I've used it on James Brudenell, 7th Earl of Cardigan and it returns an error: "The time allocated for running scripts has expired". AFAICS there's been nothing changed on the page.--AntientNestor (talk) 21:24, 19 September 2024 (UTC)[reply]

Cross post, sorry. Same as previous entry.--AntientNestor (talk) 21:26, 19 September 2024 (UTC)[reply]

New quirk, opening Wikipedia on Firefox (Chrome and Edge are fine)

Yesterday, I ran the McAfee "Tracker Remover". Normally, that's routine, and nothing odd happens, but I am wondering if my new quirk was triggered by McAfee . Normally I don't sign out when I leave Wikipedia for the day. But as of today, I'm having issues with Firefox asking me to sign in to Wikipedia. I click without password, and it opens anyway. It's just odd that it asked me to do that. If I open on Chrome or Microsoft Edge instead, both take me right into the Wikipedia page I want without asking for a password. Feedback welcome on this, please. — Maile (talk) 20:31, 19 September 2024 (UTC)[reply]

I think it is more likely that you are seeing issues of the login system itself. In layman terms, the Wikipedia/WMF login system is not as safe as Firefox would want, which leads to issues (see https://bugzilla.mozilla.org/show_bug.cgi?id=1696095 and phab:T226797 for techical details). General login issues should be better once phab:T348388 is resolved. Snævar (talk) 08:01, 23 September 2024 (UTC)[reply]
Thank you for the information. — Maile (talk) 21:13, 23 September 2024 (UTC)[reply]

Template:cot cutting off bg color on mobile

{{cot}} is cutting off bg color in collapsed state on mobile. When expanded displays properly in Talk:List of Grand Slam and related tennis records#New versions. Is this a bug or a skin issue? Qwerty284651 (talk) 10:32, 20 September 2024 (UTC)[reply]

It's about window width. It also happens in narrow desktop windows but not in wide mobile windows. The green background always stops right after the "show" link. The difference in narrow windows is that the show link moves to the left. I don't know why. PrimeHunter (talk) 11:59, 20 September 2024 (UTC)[reply]
I've eliminated your table content as a factor; that does not affect it. But the length of the title field in the collapse bar does. The first cot/cob below shows the same problem, but the second does not:
{{Cot|Version 1}}
|-
| {{lipspan|1}}
|}

{{Cot|Version 1 - same, but with a longer title field; there must be a clue here somewhere}}
|-
| {{lipspan|1}}
|}
The generated Html for the first one looks like this:
Generated Html for top example:
<div style="margin-left:0">
{|  class="mw-collapsible mw-archivedtalk mw-collapsed " style="background: transparent; text-align: left; border: 1px solid Silver; margin: 0.2em auto auto; width:100%; clear: both; padding: 1px;"
|-
! style="background: #CCFFCC; font-size:87%; padding:0.2em 0.3em; text-align:center; " | <div style="font-size:115%;margin:0 4em">Version 1</div>   

|-
| style="border: solid 1px Silver; padding: 0.6em; background: White;" |
|-
| Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
|}
Note that when expanded, the problem does not appear. Maybe this will help point the way to where to go next with this analysis. Mathglot (talk) 00:11, 21 September 2024 (UTC)[reply]
Here is a small example:
{| style="border: 1px solid"
|- style="background-color: cyan;"
| Test
|}
Test
In a narrow window, the table border is widened to the full width but the background color is not included in the widened part. Tested in Firefox in Vector 2022 and Vector legacy. PrimeHunter (talk) 09:34, 21 September 2024 (UTC)[reply]
Again the content length matters:
{| style="border: 1px solid"
|- style="background-color: azure;"
| testing whether that nation, or any nation so conceived and so dedicated, can long endure
|}
testing whether that nation, or any nation so conceived and so dedicated, can long endure
Problem gone again. But why? Mathglot (talk) 11:14, 21 September 2024 (UTC)[reply]
Also MonoBook. It's this rule: 
@media screen {
  @media (max-width: 639px) {
    .mw-parser-output table {
      display: block;
      overflow: auto;
      max-width: 100%;
    }
  }
}
For a table, the display: property defaults to display:table; which would cause that max-width: 100%; declaration to be ignored, but this rule overrides it. --Redrose64 🌹 (talk) 13:44, 21 September 2024 (UTC)[reply]
It's an unknown table, so the table defaults kick in (to allow for scrolling, in case the thing is superwide). Those defaults do not take into that something has a colored background like that and by default, the background for that element will thus not be maximum width wide, but content wide. —TheDJ (talk • contribs) 00:53, 22 September 2024 (UTC)[reply]
Have you taken the step of grabbing the right edge of your browser window, and slowly dragged it left, until you see a jump in the background color of the title bar to half the width of the title bar (meaning the right half has white backgroundd) as the window shrinks to 1/3 or 1/5 of its former width? How is your explanation related to this behavior? And, what is an "unknown table"? Mathglot (talk) 01:21, 22 September 2024 (UTC)[reply]
This would effectively be fixed if someone took the time to convert {{collapse top}} and any bottom templates (collapse bot, possibly others) to use divs rather than tables. They will need to be point person on any issues that come up. I can support. (I just don't have it in me to do it by myself. :) Izno (talk) 16:27, 22 September 2024 (UTC)[reply]
@Xaosflux: Qwerty284651 (talk) 17:09, 22 September 2024 (UTC)[reply]

Wapo

Certain Washington Post pages have inconsistent dates and metadata. User:Brownhairedgirl was dealing with this issue, she is now blocked.

  1. Category:WaPoCheckDates contains those items she identified which have not been resolved.
  2. There may well be more items with this issue by now.

I have resolved a couple by looking at the Wayback Machine history, so it is possible. The community needs to decide how we deal with both the backlog and the issue going forward.

All the best: Rich Farmbrough 21:13, 22 September 2024 (UTC).[reply]

In what way is this a technical issue? I just fixed one by comparing the date in the citation with the date on the article. – Jonesey95 (talk) 00:30, 23 September 2024 (UTC)[reply]

Pending changes on a module

I was asked to investigate a problem with {{convert}} at the Ukrainian Wikipedia. I have edited some pages there and am curious about the effect of a new user (me) editing a pending-changes protected page such as uk:Module:Convert/пісочниця (/sandbox). When I look at that page in a private window where I am not logged in, I can find "pername". I added that in the most recent edit which history shows as "pending review". Also, the pername change to the module is used at uk:User:Johnuniq/convert#pername (it shows dummy text "miPER" and "acrePER" in the output). In other words, an edit to the module which has not been reviewed still has an effect that is visible to all. This is not important—I'm just curious about WP:Pending changes. It appears that PC on a module does not achieve much other than flagging it as needing review? Johnuniq (talk) 02:58, 23 September 2024 (UTC)[reply]

I think templates work the way one would expect, I would guess Scribunto content model pages just don't... Maybe @Stjn knows. Izno (talk) 03:12, 23 September 2024 (UTC)[reply]
I just tried editing the PC protected page uk:Template:Convert/пісочниця. In a private window I could see the change to the template, and I could see the effect of the change. (I stuffed up my edit summary when I self-reverted—I meant to say that PC had no effect.) Johnuniq (talk) 03:45, 23 September 2024 (UTC)[reply]

User:Amorymeltzer/hideSectionDesktop.js

This script doesn't seem active/working anymore. Can it be fixed? Or is there an identical script? Kailash29792 (talk) 07:11, 23 September 2024 (UTC)[reply]

I would guess this broke with the headings change earlier this year. It should be fixable, but not by me. Izno (talk) 16:00, 23 September 2024 (UTC)[reply]
Pinging @Amorymeltzer. --Ahecht (TALK
PAGE) 16:43, 23 September 2024 (UTC)[reply]

Tools for formatting table cells

are there any toolbar buttons or add-ins which can be used/ added for users to format cells in a table, like changing cell BG colour?
Anish Viswa 11:05, 23 September 2024 (UTC)[reply]

No, and you should generally not want to change the background color of cells. See also WP:COLOR. Izno (talk) 16:01, 23 September 2024 (UTC)[reply]
@Anishviswa See Template:Table cell templates/doc. --Ahecht (TALK
PAGE) 16:42, 23 September 2024 (UTC)[reply]

Tech News: 2024-39

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

Weekly highlight

  • All wikis will be read-only for a few minutes on Wednesday September 25 at 15:00 UTC. Reading the wikis will not be interrupted, but editing will be paused. These twice-yearly processes allow WMF's site reliability engineering teams to remain prepared to keep the wikis functioning even in the event of a major interruption to one of our data centers.

Updates for editors

A screenshot of the interface for the Alt Text suggested-edit feature
  • Editors who use the iOS Wikipedia app in Spanish, Portuguese, French, or Chinese, may see the Alt Text suggested-edit experiment after editing an article, or completing a suggested edit using "Add an image". Alt-text helps people with visual impairments to read Wikipedia articles. The team aims to learn if adding alt-text to images is a task that editors can be successful with. Please share any feedback on the discussion page.
  • The Codex color palette has been updated with new and revised colors for the MediaWiki user interfaces. The most noticeable changes for editors include updates for: dark mode colors for Links and for quiet Buttons (progressive and destructive), visited Link colors for both light and dark modes, and background colors for system-messages in both light and dark modes.
  • Advanced item It is now possible to include clickable wikilinks and external links inside code blocks. This includes links that are used within <syntaxhighlight> tags and on code pages (JavaScript, CSS, Scribunto and Sanitized CSS). Uses of template syntax {{…}} are also linked to the template page. Thanks to SD0001 for these improvements. [1]
  • Two bugs were fixed in the GlobalVanishRequest system by improving the logging and by removing an incorrect placeholder message. [2][3]
  • View all 25 community-submitted tasks that were resolved last week.

Updates for technical contributors

  • Advanced item From Wikimedia Enterprise:
    • The API now enables 5,000 on-demand API requests per month and twice-monthly HTML snapshots freely (gratis and libre). More information on the updates and also improvements to the software development kits (SDK) are explained on the project's blog post. While Wikimedia Enterprise APIs are designed for high-volume commercial reusers, this change enables many more community use-cases to be built on the service too.
    • The Snapshot API (html dumps) have added beta Structured Contents endpoints (blog post on that) as well as released two beta datasets (English and French Wikipedia) from that endpoint to Hugging Face for public use and feedback (blog post on that). These pre-parsed data sets enable new options for researchers, developers, and data scientists to use and study the content.

In depth

  • Advanced item The Wikidata Query Service (WDQS) is used to get answers to questions using the Wikidata data set. As Wikidata grows, we had to make a major architectural change so that WDQS could remain performant. As part of the WDQS Graph Split project, we have new SPARQL endpoints available for serving the "scholarly" and "main" subgraphs of Wikidata. The query.wikidata.org endpoint will continue to serve the full Wikidata graph until March 2025. After this date, it will only serve the main graph. For more information, please see the announcement on Wikidata.

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

MediaWiki message delivery 23:32, 23 September 2024 (UTC)[reply]

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