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.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
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)
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)
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:
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. AwesomeAasim04: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)
I also moved the editnotice links to a collapsible box because the number of creatable editnotices has gotten relatively high after adding category notices. AwesomeAasim13: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. AwesomeAasim19:21, 11 September 2024 (UTC)
I would suggest to phase the rollout into stages, and creating a test plan to ensure nothing regressed. Editing this many interface pages and fully protected templates at once sounds like too much work for an admin to volunteer to. For instance, the specific category editnotices you mention can be left for later as we already have a decent system to handle those categories. Immediately, in preparation for this, I would consider adding the following category editnotices templates this cannot be done immediately as they also need to be removed from Module:Mainspace editnotice, else they would show up twice when the rest of the changes are deployed. – SD0001 (talk) 08:01, 10 September 2024 (UTC)
I actually think this might be something that is better done all in one go. Removing the two category editnotices from Module:Mainspace editnotice should be kind of a no-brainer after the rollout. The way that the module currently does these checks, checking the unparsed wikitext, currently sucks.
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}}
@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)
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 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)
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.) stjn15:09, 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. stjn19:52, 12 September 2024 (UTC)
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)
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.
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)
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)
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)
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)
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...
I'm as adamant about the use of "nounderlines" as I was ten years ago. Yes, readers are used to the use of underlines on Latin letters but it gets very confusing with unfamiliar letters/symbols. The best example is Template:Unicode chart Mathematical Operators. I contend that the change is color of the linked symbol is sufficient to alert the reader of a link.
I would like a PDF symbol in the header of the chart to the official Unicode code chart. I don't think it's intuitive to follow a reference for "As of Unicode version 16.0" to find the chart. That just buries this incredibly useful information. If you want to condense the information, what about this for the heading: Early Dynastic Cuneiform as of Unicode version 16.0 or Early Dynastic Cuneiform as of Unicode version 16.0 (official chart)
Be sure to test that the new block layout works when multiple charts appear on the same page, like Mon–Burmese script.
I don't really care which font is used for the headings/column heading but it will need to be different than the fonts (if any) for the data cells themselves. For example, Template:Unicode chart Ahom. We don't want to use Noto Serif Ahom for the entire chart, just the data cells. Not sure if the new format makes this an issue or not.
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)
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.
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)
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)
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?
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. stjn16:58, 19 September 2024 (UTC)
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)
Yes I think it should be a plain old citation in the header. The header could look like this:
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)
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)
@Sumanuil: Archiving bots don't care if a request is answered or not, and generally speaking, have no way of knowing. They work on a basis of time elapsed since the last post to that thread. However, ClueBot III has a feature where it will also archive threads that are explicitly marked with some tag, such as {{done}} even if the archiving time limit has not been reached. I see that this has been set up at Wikipedia:WikiProject U.S. Roads/Shields task force/Requests - it's the |archivenow= parameter - but that does not prevent the |age= parameter from also being taken into account. The thing to do is set |age= to a very high value - a minimum of 4368, which is six months.
Oof, horrible. This is really a WP:MOS question rather than a VPT question, but I killed that formatting with fire. The all-caps months can probably be fixed as well. – Jonesey95 (talk) 11:00, 17 September 2024 (UTC)
With fire? That was a stronger response than I was expecting. However, if you check the page history, you will see that I actually went a bit further but was reverted. I was going to post in the project talk page to discuss an overall fix – there are lots[clarification needed] of other film list articles that use that pattern — GhostInTheMachinetalk to me11:40, 17 September 2024 (UTC)
Issue is not with just one article as some people jumped in and started editing after the start of this discussion😂. Same format is there in British films and Australian films also. The fundamental question is regarding the template used for film lists (year-wise). Make or improve the template and deploy to all film lists and let us follow it. Anish Viswa 04:54, 18 September 2024 (UTC)
It is horrifying to see that this is not just a one-off problem. Thanks for the link. I opened a discussion on the article's talk page. – Jonesey95 (talk) 14:10, 18 September 2024 (UTC)
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. AwesomeAasim18:21, 17 September 2024 (UTC)
Another improvement we can do over wiktionary is take advantage of line numbers now being linkable. Ideally, the generated docs of exported functions should include links to their source code definitions. – SD0001 (talk) 20:18, 17 September 2024 (UTC)
As for this, we can already do this on this wiki: Module:Module wikitext. That is very bodgy, and it doesn't entirely make sense to me how this works or why this should work. But then, an autodoc module rendering module comments is also very bodgy, although less bodgy because reading out comments to parse from the module is less likely to break than reading out variables from the documentation module after setting them in "addText". Module comments should be taken advantage of in the parser. I did open a task (and submit my first patch to MediaWiki to complete it) for having MediaWiki only parse the contents of CSS and JS comments, see phab:T373834 (and kindly do please send more feedback on how I can improve that patch!) AwesomeAasim00:21, 18 September 2024 (UTC)
We considered generating documentation from LuaDoc when creating Scribunto, but we decided not to for the same reasons most documentation pages here are on /doc subpages instead of being inline in the template page: inlined docs can't be protected separately from the module/template and any edit to inlined docs means any pages using the module/template have to be reparsed. Anomie⚔23:50, 17 September 2024 (UTC)
I'd figure. I think of this inline doc as a good starting point for most Lua modules but ultimately there should be additional documentation that goes beyond the default functions and describes what the module exactly does. AwesomeAasim23:53, 17 September 2024 (UTC)
Yeah, being able to edit documentation without going through edit requests would be nice, even though so would be autogenerating doc sections for functions. Nardog (talk) 01:20, 18 September 2024 (UTC)
Automated cat herding is not going to work at Wikipedia. Imagine forcing every module to have comments in a fixed format with extra gunk to be machine parsable. Johnuniq (talk) 02:27, 18 September 2024 (UTC)
It is really bad practice to not put comments in code. Autodoc obviously won't work if there aren't any properly formatted comments. The goal of autodoc is to document functions and variables and more importantly module exports. Even functions in use by other modules. It never is intended to replace the module documentation page at the top of each; just supplement it. AwesomeAasim03:05, 18 September 2024 (UTC)
Yes, useful comments are great. What I meant was, it would be very difficult to get independent editors to use a fixed format. Also, I don't think documenting all functions and variables is achievable or even desirable, for example, due to the inevitable drift between hopeful comments and actual code. I do agree that exports should be documented and I once argued strongly that a module (I forget where now) should not have every function exported due to ensuing confusion and maintenance issues. I lost that argument. Johnuniq (talk) 03:34, 18 September 2024 (UTC)
There is a few related stuff I can think of.
Automatically making a list of variables is actually easy. The hard part is getting arguments in loops. See is:Module:Templatedata fyrir skriftu, which can create basic templatedata (containing only a list of variables) with the code {{#invoke:Templatedata fyrir skriftu|main|''name of module with namespace''}}.
Why not both? If there's comments in code formatted in a certain way, show them in /doc, but also allow overriding or appending to it without having to edit the module directly. Nardog (talk) 03:37, 18 September 2024 (UTC)
+1. I do think having both is useful. We can provide an end user overview at the top of the module documentation page, and a developer's overview in the autodoc. Something similar to how I implemented autodoc on testwiki:Module:Docbunto and testwiki:Module:i18n. There should be some sort of disclaimer that the documentation is auto generated and the contents can be overridden. AwesomeAasim14:42, 18 September 2024 (UTC)
Substituting Template:Documentation clears a template from Category:Pages with template loops?!
@Wbm1058 All these cite Grove templates include a copy of {{Grove templates}} in their documentation page to link between each other. {{Grove templates}} does not have it's documentation template in noinclude tags (it was deleted by accident in this edit [1]), so you end up with a documentation template in a documentation template. 86.23.109.101 (talk) 23:07, 17 September 2024 (UTC)
I dunno where the corresponding source is, or whether this is a Wikipedia or MediaWiki issue, or if there is a defect logged and/or a workaround available. jnestorius(talk)16:05, 18 September 2024 (UTC)
The caption being set to display block has always been weird to me; the other display blocks in Minerva make some sense (but I also think I've played around with this before and come to the conclusion that it was necessary?? memory is weird on this point).
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.
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)
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)
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)
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)
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)
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)
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, Dilettante20:20, 19 September 2024 (UTC)
@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)
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)
@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)
@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)
"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)
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)
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)
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)
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)
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
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)
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)
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)
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)
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.
I was asked to investigate a problem with {{convert}} at the Ukrainian Wikipedia. I have edited some pages there and am curious about the effect of a new user (me) editing a pending-changes protected page such as uk:Module:Convert/пісочниця (/sandbox). When I look at that page in a private window where I am not logged in, I can find "pername". I added that in the most recent edit which history shows as "pending review". Also, the pername change to the module is used at uk:User:Johnuniq/convert#pername (it shows dummy text "miPER" and "acrePER" in the output). In other words, an edit to the module which has not been reviewed still has an effect that is visible to all. This is not important—I'm just curious about WP:Pending changes. It appears that PC on a module does not achieve much other than flagging it as needing review? Johnuniq (talk) 02:58, 23 September 2024 (UTC)
I think templates work the way one would expect, I would guess Scribunto content model pages just don't... Maybe @Stjn knows. Izno (talk) 03:12, 23 September 2024 (UTC)
I just tried editing the PC protected page uk:Template:Convert/пісочниця. In a private window I could see the change to the template, and I could see the effect of the change. (I stuffed up my edit summary when I self-reverted—I meant to say that PC had no effect.) Johnuniq (talk) 03:45, 23 September 2024 (UTC)
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)