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.
DannyS712 bot, a bot which is supposed to look after various daily or weekly maintenance tasks, hasn't made any edits since July 1, including failing to update Wikipedia:Database reports/Polluted categories (2) in eleven days despite that being a thing that's supposed to happen weekly, but the bot's maintainer says on their own userpage that they're not around much lately, and they haven't made any Wikipedia edits at all since July 3, so there's no way to know when they'll be back in order to look into it if I approach them personally (especially in July, when any editor could very well be on vacation for a couple of weeks). So could somebody take a quick gander into whether there's a problem with the bot, and maybe jumpstart it again if there is? Thanks. Bearcat (talk) 15:53, 12 July 2024 (UTC)[reply]
I saw the ping, and have been meaning to get to this, but am aware of the issue - hopefully I'll have time this weekend, and sorry for the delays --DannyS712 (talk) 21:07, 12 July 2024 (UTC)[reply]
Nobody said otherwise. The problem is with a bot not functioning properly for purely technical reasons, and absolutely nobody accused Danny of anything improper. Bearcat (talk) 14:39, 20 July 2024 (UTC)[reply]
I guess I just got the weekend wrong, I was out of town for a while - I definitely should have time this week, maybe even tomorrow DannyS712 (talk) 02:40, 21 July 2024 (UTC)[reply]
No worries. I was able to use the substitute on-the-fly report provided above to work around the bot issue, so the delay hasn't been a major crisis. Bearcat (talk) 14:04, 21 July 2024 (UTC)[reply]
When I edit admin-protected pages like Template:Disambig editnotice, I get nearly-white text on a very light pink background, and it's nearly invisible. Does anyone know where this color is set? Is that part of the skin CSS?
BTW, I added class=skin-invert to that template, but the results are pretty ugly in dark mode. It (and many other templates) could probably use upgrading to CSS variables with the palette from [1], though it's very difficult for me to edit it safely at the moment. -- Beland (talk) 03:46, 20 July 2024 (UTC)[reply]
I've thrown Something at the problem now that I've been reminded about at least 5% of why I asked for int admin back. We're going to need to refine colors, these don't necessarily mesh well with syntaxhighlighting, which is still a known problem child. Izno (talk) 04:07, 20 July 2024 (UTC)[reply]
(Alternatively, we can ditch the pink for editing protected things and just use the base colors, but IDK how that will go down with Everyone.) Izno (talk) 04:10, 20 July 2024 (UTC)[reply]
I know what the purposes of the background is, I am just about convinced however that it isn't valuable to load for every user in the groups of interest. Izno (talk) 16:34, 20 July 2024 (UTC)[reply]
I'm now getting white text on a dark red background in dark mode, which makes things a lot easier to edit in dark mode. Many thanks! I'm still curious where this fix was implemented, in case I run into similar problems elsewhere? -- Beland (talk) 19:03, 21 July 2024 (UTC)[reply]
As for the BTW, this template strongly needs to reconsider whether it should have the (coffee) color it does. It is intended as a system message (edit intro) and should be colored as expected for that series of templates. It looks like it was added based on "it would be more noticeable", which I think is a miss since most other edit notices are no more noticeable. But particularly to using a Codex color, there are no coffee colors in that palette. Izno (talk) 04:15, 20 July 2024 (UTC)[reply]
I've changed it to "background-color-warning-subtle" from the official palette, which is more or less the same hue. It still ends up as an ugly brown in dark mode, even without "class=skin-invert". Presumably there needs to be an official thinking up of a good subtle warning color for dark mode?
Whether this should be notionally colorized as a warning or as info I'm agnostic about. Looking through the templates in Category:Editnotice templates, the aesthetics are really all over the place. Some templates get attention by having a yellow icon, red icon, yellow border (which is nice even in dark mode), red words as internal headers, yellow background, or pink background. Some have no attention-getting colors at all. Should we start a discussion somewhere about making the visual conventions more uniform? If these are all going to need to be converted to use the new official palette, they'd need to be adjusted anyway. -- Beland (talk) 19:22, 21 July 2024 (UTC)[reply]
I wouldn't be surprised by an ugly brown being the flip for yellow. Using the skin-invert class should be used only for non-flipping colors, and this isn't one of those.
We don't need to convert to Codex per se, we just need to be sensitive to what colors we have and are providing in multiple color themes now. Having a standardized color scheme (which we in fact already have for the message box series, though as you point out it is often customized) is one way to be successful at that objective by default. Adding the customizations that we do is the issue, and could be solved either by removal of those colors, making some other standard templates/templatestyles, or using upstream variables from Codex or even Common.css. A discussion about the customizations is probably warranted somewhere, but I don't know how many people are interested in that kind of topic - often there is resistance along the lines of "it looks like how I wanted" (which would echo refrains from when the message boxes were standardized nearly 20 years ago). Izno (talk) 19:35, 21 July 2024 (UTC)[reply]
i read about half this thread and understood less than that, but one thing i think i understand was what Redrose64 said: The pink reminds me that I'm editing a protected page, and that I need to exercise extra caution. What if the pink were added as a border around the browser window or editing area instead of a background that potentially camouflages the text? Would that be an equally effective reminder? and maybe do similarly for other "alerts"? i don't know how many such color-coded alerts exist; i'm an anonymous IP rather than a registered user or admin, so i guess i don't see some of these things. But maybe instead of having light-mode-black-on-white-(and-sometimes-black-on-pink) change to dark-mode-white-on-black-(and-sometimes-white-on-dark-red-or-yellow-on-ugly-brown), maybe instead light mode and dark mode could just toggle black-on-white to white-on-black with both sharing the "double word score" pink border (or maybe a border of pink-and-red stripes like these, or Battenburg markings) for Alert Type X, and for Alert Type Y light and dark mode can share a "triple letter score" shade(s)-of-blue border, and so on like that?
I like the idea of moving the warning color out of the background and into a border or eye-injuring stripes above or below the edit box. That prevents any conflict with syntax highlighting, the authors of which probably aren't expecting a background color that only admins see. -- Beland (talk) 16:19, 26 July 2024 (UTC)[reply]
So I rrecently used my iPhone to access the Teahouse and the scrreen flickered between normal and black for about 10 seconds before going all black. Restarting the app doesn't fix this either. Unfortunately I have no image of this, but to describe it:
The screen would flicker between being able to read, then white, then flickering black.
Then the screen would stop flickering and go all-black. This isn't an issue with my device, as only a few pages within the Wikipedia app in specific do it.
Every part of the screen was black except the upper search bar and the Wikipedia logo.
Then I atttempted to restart the app and see if the glitch would go away, but it kept doing it.
I noticed that extremely long pages or threads will completely black-out iPhone screens (including the Teahouse, which is notoriously long). This can be a serious issue when trying to access something in-the-moment, and the Teahouse still is completely broken on my phone. I have no idea if this is even a Wikipedia-side issue, but yea. Just anted to make ya'll aware of this. I'll try to get an image tomorrow, it's prretty hard to explain. Sir MemeGod ._. (talk - contribs - created articles) 04:16, 22 July 2024 (UTC)[reply]
I'm Amal Ramadan, Senior Movement Communications Specialist supporting the mobile apps team at the foundation, can you send the model and iOS version of your device, please? I will forward it to our iOS engineers to work on solving it.
Also, you can follow with us through the iOS support email: ios-support@wikimedia.org
Apologies if this is not the right place for my query. While using the Wikipedia app on iOS with a 4G connection, I received a notification from my provider stating I had only 5GB left in my data package. Eight minutes later, I received another message saying my data package was completely used up. Upon checking my cellular usage settings, I found that the Wikipedia app had consumed 6.8GB of data in just about 10 minutes. What could be the cause of this? 141.196.107.237 (talk) 05:08, 22 July 2024 (UTC)[reply]
I visited articles including the 2024 US presidential elections, January 6 Capitol attack, Trump assassination attempt, Joe Biden presidential campaign 2024, and the 2024 presidential debate. I’m not sure that these articles would use 6.8GB of data in such a short time. 141.196.138.120 (talk) 07:04, 23 July 2024 (UTC)[reply]
141, do you happen to have a large Reading List of articles saved for offline viewing? Is it possible that it was syncing across devices or refreshing its contents for another reason?I'm afraid most of us editors at English Wikipedia have very little experience with the apps, since they don't support full editing functionality. Someone here may have answers for you, but in case none are forthcoming, you could always ask the iOS app team directly at mw:Talk:Wikimedia Apps or at the technical support email address listed at :mw:Wikimedia Apps/iOS FAQ § If I have a question or a suggestion, how do I get in touch?Folly Mox (talk) 09:58, 22 July 2024 (UTC)[reply]
I'm Amal Ramadan, Senior Movement Communications Specialist supporting the mobile apps team at the foundation. After discussing this issue with our iOS engineer lead, we have created a ticket T370790 for further investigation. Please subscribe to it for updates. It would also be helpful if you could let us know if you were reading only or using multimedia options in the article as well. ARamadan-WMF (talk) 08:13, 24 July 2024 (UTC)[reply]
If that subject line does not look cryptic to you, I would love to have your advice. I am trying to spin off the table about License compatibility that you can view here, into a template so I can use it in multiple articles, and add user-configurable style, and I am running into problems using CSS to reproduce the blue background in the first row. Currently, the template is at Draft:License compatibility. I am busy on two tracks: adding parameters for user stylability, and moving the original style to Draft:License compatibility/styles.css as default style. In trying to reproduce the original table style with the blue background and bolded white font in the top row as seen here, I tried the following at Draft:License compatibility/styles.css:
but it doesn't seem to be working properly; instead of rendering the top row with blue background, it is rendering the *second row* with blue background, and I don't understand why. Thanks for any tips you can offer. Mathglot (talk) 09:33, 22 July 2024 (UTC)[reply]
All rows in a wikitext-generated table are in <tbody>, not <thead>, even if the first one(s) include only <th>s. If the table is sortable, jquery.tablesorter puts the first row in <thead> for JavaScript-enabled users. You should probably add a class to the row itself rather than rely on a pseudo-class. Nardog (talk) 09:45, 22 July 2024 (UTC)[reply]
Thank you very much from this response. The table is non-sortable. When I look at the generated Html, I see this:
Html for table
<tableclass="wikitable lic-comp"><tbody><tr><thcolspan="2">License Compatibility with Wikipedia<supid="cite_ref-1"class="reference"><ahref="#cite_note-1">[1]</a></sup></th></tr><tr><td><spanclass="heading">Licenses compatible with Wikipedia</span></td><td><spanclass="heading">Licenses <i>not</i> compatible with Wikipedia</span></td></tr><tr><thscope="row"colspan="2"><spanclass="lic-comp-label">Creative Commons licenses</span></th></tr><trstyle="vertical-align: top;"><td><ul><li>CC BY, all versions and ports, up to and including 4.0</li><li>CC BY-SA 1.0, 2.0, 2.5, 3.0, 4.0</li><li><arel="nofollow"class="external text"href="https://creativecommons.org/share-your-work/public-domain/cc0/">CC0</a></li></ul></td><td><ul><li>CC BY-NC</li><li>CC BY-NC-ND</li><li>CC BY-ND</li><li>CC BY-NC-SA</li></ul></td></tr><tr><thcolspan="2"><spanclass="lic-comp-label">Other licenses</span></th></tr><tr><td><ul><li>GFDL <b>and</b> CC BY or CC BY-SA</li></ul></td><td><ul><li>any GNU-only license (including GFDL)</li></ul></td></tr></tbody></table>
so it seems like the first tr child should be the top row, not the second one. Are you saying that jquery alters the Html after the capture posted here from right-click, view page source? Mathglot (talk) 09:55, 22 July 2024 (UTC)[reply]
If it's sortable, yes. I know it doesn't pertain to this table since it's not a data table and so is unlikely to be made sortable, but it's good practice to not rely on :first-child or :nth-child to select header rows because jquery.tablesorter modifies them for a subset of users. Nardog (talk) 10:00, 22 July 2024 (UTC)[reply]
Thanks. I'll try a different approach, although I'm not sure how to address a row in a wikitable, unless I convert it to an Html table first, and then I have the row and cell tags available which I can address. Maybe that's where this should go, at this point, unless there is an alternative. Mathglot (talk) 10:08, 22 July 2024 (UTC)[reply]
Sjoerddebruin, you may be right, but as I am spinning off content written by another editor into a Template, I feel like the first effort should exactly reproduce their original design, so I can introduce the template into the article where they originally added the wikitext, without any changes to the rendered page. The parameters being added to the template will provide configurability to other users, to alter it as they see fit. Thanks for your comment. Mathglot (talk) 10:19, 22 July 2024 (UTC)[reply]
I don't see any blue background or white text. Have you enabled "Make headers of tables display as long as the table is in view" at Special:Preferences#mw-prefsection-gadgets? That also messes with unsortable tables. I get blue background and white text in the top row with this which adds thto your code:
Oh, I must have misunderstood something then. I thought Mathglot was trying to turn "Licenses compatible with Wikipedia" and "Licenses not compatible with Wikipedia" blue. Nardog (talk) 10:40, 22 July 2024 (UTC)[reply]
They are blue now, that is the problem. For starters, I am trying to echo the original, which is here, using templatestyles instead of inline style. So far, I haven't managed to do it. That would be the baseline, from which user configurability could begin. Mathglot (talk) 10:46, 22 July 2024 (UTC)[reply]
At this point, I'm going to take a break, but I should add if anyone wants to play with the template, this is a wiki, so by all means, please try stuff out in the template, or the styles.css, if you have an idea how to progress with this. Thanks, Mathglot (talk) 10:50, 22 July 2024 (UTC)[reply]
I just made the draft table much simpler (and I believe more accessible), feel free to revert if it's too drastic a change. Nardog (talk) 11:09, 22 July 2024 (UTC)[reply]
Oh, in that case it's because the default background applies to <th>, not <tr>, so it takes precedence over your custom style in TemplateStyles. .lic-comp tr:first-child > th is one way to do it. Nardog (talk) 10:50, 22 July 2024 (UTC)[reply]
@Mathglot: You didn't answer whether you have enabled "Make headers of tables display as long as the table is in view". If I enable it then I get the result you describe with blue in the second row. Without it, my code works for me, but it would be better to not rely on which table-altering features are used. PrimeHunter (talk) 11:00, 22 July 2024 (UTC)[reply]
@PrimeHunter:, Oh, thanks for thinking of that—yes, I do have header view enabled, so is that interfering somehow? I did check the page Html and didn't see anything suspicious, does the header gadget maybe change the th to something else after the page Html snapshot is taken for developer tools? In any case, what if I assign the row an id attribute, maybe I could use that to address the row uniquely regardless whether it was th or something else. Is that even possible in a wikitable, I'm not sure I've ever tried to assign a row an id attribute, and I don't see anything at Help:Table about it. Mathglot (talk) 07:45, 25 July 2024 (UTC)[reply]
@Mathglot: Page Source in Firefox shows the original html but when I right-click the heading and use Inspect Element, the gadget has changed <tbody> in the first row to <thead class="mw-sticky-header-element">. tbody is still in the second row so your CSS matches there instead. id's can be applied to rows like |- id="header" which can be targeted with #header th {...}. I often use row id's to link to a row. See Help:Tables and locations#Section link or map link to a row anchor. PrimeHunter (talk) 10:38, 25 July 2024 (UTC)[reply]
@PrimeHunter:, very cool; this is just the information I needed, on both counts. They ought to give out Affinity Cards or something, and questioners get to award points to responders, and after you win 10,000 points or something, they fly you out to the next Wikimania or something. I'll skip the virtual cookies and fruit, but really, big thank you; also to Nardog and others who took the time to respond. Mathglot (talk) 05:53, 26 July 2024 (UTC)[reply]
I am often editing dates in citations manually, there might be tools to help? Specifically things like converting all |date= to mdy/dmy, and converting certain parameters to iso. Do tools like this exist? -- GreenC17:06, 23 July 2024 (UTC)[reply]
You know, there are reasons to edit the source, for instance there are editors with disabilities for whom the source code is already pretty unreadable. I recommend that editors continue to fix all instances of YYYY-MM-DD formatting until a system-wide solution can be found. Abductive (reasoning)04:48, 25 July 2024 (UTC)[reply]
I would like to edit the headings so that they are one level down like in here. I know I could probably do it the old-fashioned way, but it would probably take up a lot of time to do so. I'm looking for an easy solution that I can use so that it will bring the headings one level down. For example: if it is a level 2 heading, I would like it into a level 3 heading. What would you recommend I do? Please ping me in your response. Interstellarity (talk) 23:23, 23 July 2024 (UTC)[reply]
@Interstellarity, this will probably work with the regex find replace in the wikitext 2010 or 2017 editors: find ==([^=]*?)==, replace ===$1===, mark the find as a regex find, and then hit the appropriate go button. Izno (talk) 23:46, 23 July 2024 (UTC)[reply]
@Izno: How can I do this for turning level 1 headings into level 2 headings, level 2 headings into level 3 headings, and level 3 headings into level 4 headings, and so on? Interstellarity (talk) 00:26, 24 July 2024 (UTC)[reply]
Perhaps this is impossible, but I noticed that Talk:AC/DC is technically a subpage of the unrelated Talk:AC disambiguation, merely due to the backslash's double function as a title & subpage sorter (classic Wikipedia shenanigans). Is this removable somehow? Not a huge issue, but certainly not ideal either. Aza24 (talk)06:18, 24 July 2024 (UTC)[reply]
We could hide the parent page link to Talk:AC with .page-Talk_AC_DC .subpages {display:none;} in MediaWiki:Common.css but I don't support it. Each unwanted link would need its own code and the increased CSS size doesn't seem worth it. It would still be a subpage with other associated features. PrimeHunter (talk) 10:41, 24 July 2024 (UTC)[reply]
On this page, Wikipedia:Vital articles/Level/4, when I click the edit link on a particular section, any section, it brings me to the section before the one I clicked. I recently transcluded the sections so I'm not sure if this is part of the problem and it is buggy right now since this is new, but I am working on it to try to bring it so it can be stable and free from bugs. Interstellarity (talk) 22:00, 24 July 2024 (UTC)[reply]
@Jonesey95 The problem isn't with the subpages, it's with the main page of level 4 that I'm trying to figure out. I saw that you replicated the problem, but I am unaware of a null edit that caused the problem to go away. Interstellarity (talk) 22:17, 24 July 2024 (UTC)[reply]
@Interstellarity I would recommend undoing your transclusion of those sections, as it causes the page to be huge, take forever to load, and, most importantly, exceed the WP:PEIS limit so that the entire thing doesn't display properly. It also may have broken Cewbot, as seen at this edit right after your transclusion. --Ahecht (TALK PAGE)13:58, 25 July 2024 (UTC)[reply]
When a wikilink on a page points to that same page, it displays as bold rather than regular blue. These are not clickable links, as one is already on that page. As of...recently...however, the mouse cursor over these items still turns from the normal pointer into the hand as if it were a regular link. Vector2022, Firefox-115.13.0esr. Examples tested are [[User:DMacks]] on User:DMacks and spot-checking several navboxes (mainspace pages that transclude templates with a link to the mainspace page). DMacks (talk) 22:38, 24 July 2024 (UTC)[reply]
I use Wikipedia on my laptop and PC, which both have roughly the same size screens. Now, I haven't made any setting changes, and everything is fine on my laptop, but on my PC, out of the blue, Wikipedia is no longer using the full page width. For some things! Talk pages are fine, infoboxes are where they should be, same with end of article templates and category lists. It's just the article text itself (and any images in the article) that isn't using the full screen - its right-hand border is roughly in line with the standard infobox position. I've taken a few screenshots to illustrate the problem.
@Bertaut, this is something that I might expect to happen if you turn on the "Improved appearance for mobile, narrow and wide screens (documentation)" in your gadgets in Special:Preferences. Can you see that is unchecked?
Second step, if that is unchecked, please go to a page of interest and add ?safemode=1 in the URL bar and then hit your version of "go" and see if the issue persists. Izno (talk) 00:29, 25 July 2024 (UTC)[reply]
That appears to have fixed it; that option was checked. Can't believe it was that simple!! The fact that I didn't have the problem on the laptop made me think it wasn't a Wiki setting. Really appreciate that. Thanks. Bertaut (talk) 00:34, 25 July 2024 (UTC)[reply]
For dark mode: How should a template change the "background-color" property?
We have a dark mode now, but I'm confused about how templates should handle background colors. An editor raised a specific issue at Template_talk:Bar_chart#Dark_mode_error, and I asked that individual, but maybe other people will have this same confusion.
The issue is that many templates use a pale (but not white) background to set boxes aside from the main content. These templates typically leave the "color" property of text alone. The default color is black but becomes white in dark mode. The resulting pale text on a pale background is unreadable. For example, activate dark mode and check out Prince Albert, Saskatchewan#Demographics. The glowing template there is {{Canada census}}. It uses the background colors #f8f9fa and lavender and does not change the "color" property of the text.[6] This seems to be a bug in dark mode, but I see many similar templates listed at this bug-tracking page as if they are template bugs: [7]
The recommendations from the WMF seem to suggest defining a light and dark background color on each template?[8] If that's the answer, then that's the answer, but seems like a massive amount of work when templates exist for years without being fixed for mobile, screen readers, narrow screens, the new desktop theme, and so on.
Also, what does this mean for templates that allow a user to set the background? On {{bar chart}} this would make the text unreadable on at least one of the two modes, and so user-determined colors would need to be disabled.[9] I looked up a version of Elie Wiesel that I know has the background-color set at the page level for its {{quote box}}es.[10] I see "html.skin-theme-clientpref-night .quotebox:not(.notheme)" disabling both "background" and "color" properties at the site's theme level. This appears to have been done for many widely used templates (infoboxes and nav boxes), but what is expected for other templates?
I imagine the background colors cannot just be turned off because templates like {{legend}} use them for meaning. But is there no way for the site to automatically figure that black text with a custom background color should not become white? Rjjiii (talk) 05:57, 25 July 2024 (UTC)[reply]
The fact that stuff wasn't fixed for years isn't a reason to continue doing so. A lot of user selected colors don't pass WP:COLOR's AA minimal requirement. Gonnym (talk) 07:13, 25 July 2024 (UTC)[reply]
Personal opinion is that setting color is generally unnecessary in 'structural' templates like infoboxes. Simply getting a template to output a background compatible with the theme is usually enough. Izno (talk) 17:34, 25 July 2024 (UTC)[reply]
Finding the rest of the issues is a matter of finding contrast issues. Do not try to assign a text color to every background-color, it is a waste of time with no real benefit. Only assign a text color if the contrast is insufficient according to WCAG AA.
You want to take the hex color values of #101418 which is dark mode background and #6D8AF2 which is the link color. Hex values close to those have insufficient contrast. I recommend finding the first available contrast friendly color and search for everything that has less contrast (you can use https://webaim.org/resources/contrastchecker/ to find this color). The search can be done with an regex. Additionally "background:transparent" is also an issue, and should probably be removed on sight.
I think most of your questions are answered above. TheDJ links to the page most of interest to the question. Some specifics:
There is a design token background-color-neutral-subtle which in light mode is a near-white grey. I have been normalizing templates to that color as the base when I encounter a near-white. In the case of the census template, it is the exact same color in light mode as you have pointed out. (It's probable that I'm the one to blame: I would have added that color to the template when I was removing the use of infobox class from non-infoboxes.)
For the specific case of templates that allow the user to change the color:
Remove allowing the user to change the color. This may or may not be feasible either technically (because it does not fit the semantics of the template) or because you're afraid of screeching from users who have always done it that way and have not had a care in the world about how unable it makes us to provide a dark mode. Either way, if you think you can get away on the second axis, strongly go for the first.
Do a hard override in TemplateStyles (e.g. Template:Color/styles.css, because that template matches the first case above) or at a global level (we have some generic CSS in MediaWiki:Vector-2022.css that hits a bunch of cases).
seems like a massive amount of work when templates exist for years without being fixed for mobile, screen readers, narrow screens, the new desktop theme, and so on. Welcome to Wikipedia. Identify priorities and backlogs (for example, MediaWiki talk:Common.css/to do), advertise that you're working on it ( ;) ), fix things that affect you personally when you find them, and ultimately, do what you can. Izno (talk) 17:56, 25 July 2024 (UTC)[reply]
Thanks all! Izno and TheDJ's post covered everything. Appreciate the explanations. I was hoping there would be a simple solution, but can accept there is not, Rjjiii (talk) 22:16, 25 July 2024 (UTC)[reply]
I'm a first-time technical contributor, so I'm not entirely sure if this is the best place for this request, but I believe kickstarting a conversation here is a good start. I've just created my first module in Lua and would welcome feedback and a review from the more experienced technical members of our community.
The module, Module:Korean transliteration notice, is designed to support articles about Korea. Unfortunately, there is no universal method for romanizing the Korean language, with the two Korean governments having different standards and Western academia preferring another.
According to the MOS:KO, there are established conventions for which articles should use which method, but there is currently no categorization, automation, enforcement, or awareness among many editors and a template like this would help greatly and be a good first step.
Don't know Korean? Don't worry. This module is designed to work very similarly to Module:English variant notice, which I used as a foundation for the transliteration module. Here are some key links to the documentation and example template outputs:
No globals. Add require('strict') at the top. Do you really mean to export all of the functions in the module? If not, then functionp.whatever() should be changed to localfunctionwhatever() (may require repositioning in the module).
Performance considerations There are some cases where you should worry about performance (templates widely used like millions of pages, or several hundred uses per page, or the modules are huge), but otherwise, don't worry about it. Izno (talk) 18:01, 25 July 2024 (UTC)[reply]
Note: I originally intended to ask the devs to make the system message add the category but this has been proposed in the past in phab:T289404 and was declined. This is why I think adding the template manually is the best approach. Nickps (talk) 16:03, 25 July 2024 (UTC)[reply]
The code for {{Documentation subpage}} has a test that looks like it tries to assign a category: ... [[Category:{{#switch:{{SUBJECTSPACE}} |Template=Template |Module=Module |User=User |#default=Wikipedia}} documentation pages]] .... My naive question is: why isn't that code working? Does an if statement need to be redesigned? Can something else be tweaked inside that template? I'm not clear on how the page-header page "adds" the doc subpage to the template without actually transcluding it; maybe the category could be "added" in the same way that the doc subpage template is "added". – Jonesey95 (talk) 16:19, 25 July 2024 (UTC)[reply]
I will stop. But you're not explaining what's so dangerous about them. They can be reverted as easily as I am doing them. Nickps (talk) 17:07, 25 July 2024 (UTC)[reply]
10 minutes of edits done manually can be reverted in less than half that by someone with AWB. I'm not creating a fait accompli and I'd like you to take that back. Nickps (talk) 17:11, 25 July 2024 (UTC)[reply]
(edit conflict) What's dangerous is explained in the essay I linked - it inappropriately biases the situation toward the automatic documentation being removed later because the edits required to do it are already in place. The cost of this is that every time a module is created {{documentation subpage}} has to be manually added to the subpage forevermore, and I'm not seeing what the point of Category:Module documentation pages even is when the search I linked above can produce the same output in the unlikely event anyone cares. * Pppery *it has begun...17:12, 25 July 2024 (UTC)[reply]
Hello, I found a problem on Commons. The problem is with images in SVG format, where there is distortion in the display of the text of the image, a change in the location of the text display, and a difference in the size of the text display.
This is a sample image, please click and view. So if you click on it, it will appear to you like this.
I thought the problem was due to the program I use to edit photos. For about a full day, I was experimenting with solving the problem, trying different size dimensions and so on, but it was not solved. Then in the end I discovered that the cause of the problem was the Commons website and not me.
I was also able to find out the reason for the problem on the Commons website. It occurs because the text is in a large size, and if you reduce it, the text size will be displayed at approximately the correct size.
Therefore, I ask that the technicians responsible please fix this defect, because it is a major problem. I have stopped editing images until the problem is fixed. Unfortunately, many people must have stopped designing images in this format and uploading them to Wikipedia articles because of this problem.
Note: I do not want to raise the discussion within the Commons project, because it is a very important problem related to the display of images in Wikipedia articles, and Because there is no interest from technicians within the Commons project. Mohmad Abdul sahibtalk☎talk21:55, 25 July 2024 (UTC)[reply]
How do you know technicians from the Commons project wouldn't be interested in this issue if you haven't raised it there? Tule-hog (talk) 22:06, 25 July 2024 (UTC)[reply]
@Tule-hogYou can take a look here There are problems raised a year ago that have not been answered. Also, the problem I raised is urgent and important. I have stopped all my projects until the bug is fixed. In addition, the problem is linked between the two projects. Mohmad Abdul sahibtalk☎talk19:42, 26 July 2024 (UTC)[reply]
Not saying you shouldn't have raised it here, just that you might also try raising it there to increase coverage. Arabic's SVG rendering possibly not working is a serious, global bug to be sure. Have you happened to find any graphics that don't have the issue? Tule-hog (talk) 02:58, 27 July 2024 (UTC)[reply]
I think the problem is that your used the Arial font in your image, which is not a free font, and thus is not installed on the Wikimedia servers. Try changing the text in the image to use one of the fonts listed here: https://meta.wikimedia.org/wiki/SVG_fonts – I suggest Liberation Sans, which was designed as an alternative to Arial – and see if that makes it display right. Matma Rextalk22:28, 26 July 2024 (UTC)[reply]
@Matma Rex: Nope. I have tried (LiberationSans-Bold), and the problem is the same. There has only been a slight difference in text measurements, but text distortion, positioning, and size are still there. Mohmad Abdul sahibtalk☎talk02:50, 27 July 2024 (UTC)[reply]
Hmm, you're right. I uploaded a new version of the file (File:Anterior Thyroid - Arabic.svg) just to be sure, and it still looks very wrong. I want to try some other things, but I'm not sure how the result is supposed to look like – the SVG file on my computer also has slightly weird-looking text, and I'm not sure if it's a problem with the file or with my applications: https://phabricator.wikimedia.org/F56717722. Can you export it to PNG on your computer and upload that version to Commons too, so that we may compare? Matma Rextalk03:34, 27 July 2024 (UTC)[reply]
@Matma Rex: I think I discovered the cause of the problem, it is caused by a difference in dots per inch. Because I downloaded an image in SVG format for the year 2010 and wanted to modify it, but I saw this message inside the program:
was created in an older version of Inkscape (90 DPI) and we need to make it compatible with newer versions (96 DPI). Tell us about this file. This file contains digital artwork for screen display (Choose if unsure.) This file is intended for physical output, such as paper or 30 prints. Create a backup file in same directory. More details: We've updated Inkscape to follow the CSS standard of 36 OPI for better browser compatibility we used to use 50 DPI. Digital artwork for screen. display will be converted to 96 DPI without scaling and should be unaffected. Artwork drawn at 90 DPI for a specific physical size will be too small if converted to 96 DPI without any scaling. There are two scaling methods. Scaling the whole document: The least error-prone method, this preserves the appearance of the artwork, including filters and the position of masks etc. The scale of the artwork relative to the document size may not be accurate. Scaling individual elements in the artwork: This method is less reliable and can result in a changed appearance but is better for physical output that relles on accurate sizes and positions (for example for 3D printing. More information about this change are available in the Inliscape
I have installed Inkscape version 0.48 (2010). Then I tried editing the image and uploading it to Commons, and I did not see any distortion or any problems with the text.
__________________
There is another problem, which is when you open the image in this way, right-click on it and then download it directly, without clicking on the download icon, the image is not downloaded in SVG format, but rather in PNG format, and this is a big problem that should not happen. Mohmad Abdul sahibtalk☎talk04:55, 27 July 2024 (UTC)[reply]
@Matma Rex: This is the original image. We do not have distortion problems with PNG images because their texts are more like printed matter or more like hardsub, meaning that the text is not editable, nor are the image objects. As for SVG files, they are more like an image project that can be edited and translated, including the text. I work with SVG images so that they can be easily modified and translated into other languages. I hope in the future that Wikipedia's policy will change so that it does not allow uploading any PNG images of any images with text on them.
In fact, I suggest that Wikipedia provide the feature of translating SVG image texts without the need to upload them repeatedly for each language. This will facilitate the work and reduce the size of the Commons server data. I mean, if the Commons project provides us with the advantage of recognizing image texts and translating them so that they are displayed directly without the need to repeatedly upload the image in each language, then the matter will become easier and faster and will save space on the Commons project server. Mohmad Abdul sahibtalk☎talk05:16, 27 July 2024 (UTC)[reply]
SVG image rendering is done using librsvg, if you have problems with how the image renders it is probably a problem in the librsvg library. We don't do direct work on developing the software that renders the SVG (it is a dependency). If you find the issue, perhaps you can report it with the librsvg project. —TheDJ (talk • contribs) 08:50, 27 July 2024 (UTC)[reply]
" I suggest that Wikipedia provide the feature of translating SVG image texts without the need to upload them repeatedly for each language" You are welcome to write such functionality for MediaWiki. Most of this kind of functionality is written by volunteers. —TheDJ (talk • contribs) 08:58, 27 July 2024 (UTC)[reply]
The user stated they wish to do this without having to reupload for each translation. While svg translate allows combining translations into a single upload, each edit to them or each new translation still requires a reupload. —TheDJ (talk • contribs) 08:54, 28 July 2024 (UTC)[reply]
"right-click on it and then download it directly" then you are downloading the thumbnail, and this is expected. If you want the original file, you always need to use the link below it "original file" and choose Save file as. —TheDJ (talk • contribs) 08:48, 27 July 2024 (UTC)[reply]
Thanks for all this information.
@TheDJ: yes, I know this. I meant that the image must be downloaded in SVG format even if it is clicked directly without clicking on the download icon - otherwise some people may not pay attention to the download icon and a problem and suspicion will occur.
@The wubThe wub: This is something legendary, I didn't know about it. But I have a problem, which is when I access a Commons project in English, its interface will switch to Arabic. Unfortunately, the Commons project cannot be accessed according to the desired language، and unfortunately, the (Content Translation/V2) is not available in this project, and for this reason I cannot translate many explanatory articles in the Commons project. I hope that the Commons:SVG Translate tool icon is present on the information page of every SVG image uploaded to Commons, so that everyone knows that this feature exists, whether writing on images or translating them.
I have informed the members of the [[librsvg] project, and am waiting for their response to find out if the problem is due to the library. We still need to find out the cause of the malfunction, to determine the cause of the problem, any information about this would be helpful. I hope that we will cooperate in fixing the defect, because the problem is related to a major error related to Wikipedia, especially the display of images. I have currently stopped all my projects related to image design, because if I now upload images with small texts in them so that they will be displayed in a large size, it is expected that after fixing the defect, the text size will decrease.Mohmad Abdul sahibtalk☎talk08:05, 28 July 2024 (UTC)[reply]
Hello - I was using {avoided double redirect} incorrectly and creating redirect categorization redundancy on edits on my account from before July 19, 2024. I would like to request anyone with experience with automation to run a (hopefully already existing) script to prune redirects created by my account - that is, removing redundant categorization from redirects using {avoided double redirect}. Alternatively, any helpful pointers to completing this task on my own would be appreciated (should I try AWB?). Tule-hog (talk) 22:04, 25 July 2024 (UTC)[reply]
That page also hassomecharts that are mostly white. Of course image files don't change color (well, GIF files might, but i don't think they're the solution here), but it's something else to consider.
Village pump (Policy - Technical - Proposals (persistent) - Idea lab - WMF - Miscellaneous)
and this part
Village pump (technical) archive This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic. < Older discussions · Archives: A, B, C, ... 212, 213, 214
appear as dark text (including blue links that turn purple after clicking them) on a light background. The list of archives includes 42 as hard-to-see #light text on a light background in dark mode.
The GIF article has an infobox that says (more or less)
Filename extension: .gif Internet media type: image/gif Type code: GIFf Uniform Type Identifier (UTI): com.compuserve.gif Magic number: GIF87a/GIF89a
but ".gif", "image/gif", and "GIFf" appear as dark text on a light background. "GIF87a" and "GIF89a" seem to switch with light mode/dark mode, maybe by using <code>THIS</code> instead of {{code|THAT}}?
"Parts of these pages have dark text on a light background" yes this is expected. There is 25 years of legacy and fixing all these templates to have both a light AND a dark mode will take multiple years and require new decisions to be made. The highest priority however right now is to ensure we do not have dark on dark or light on light, as that effects readability. The 'is it pretty' issues will be dealt with in good time. —TheDJ (talk • contribs) 08:55, 27 July 2024 (UTC)[reply]
Agreed: This is not a top priority. However, as someone unfamiliar with coding, i don't always know if a problem here is related to a problem there, so sometimes i ask others i think might know (or might know how to find out). Also, even if the issues are unrelated, a small issue might still deserve to be on the to do list (even if way, way down on the to do list), so i hope mentioning it is useful. --173.67.42.107 (talk) 19:44, 27 July 2024 (UTC)[reply]
TheDJ, well, in this case it's a combination of the SyntaxHighlight extension not supporting dark mode, which we can't do much about, and {{code}} using the syntaxhighlight tag, when it could use the code tag if no langauge is specified. — Qwerfjkltalk19:56, 27 July 2024 (UTC)[reply]
i've done a bit of Wikipedia browsing and editing on my smartphone, mostly in dark mode since i learned it was an option (Wednesday July 10?).
On my laptop, wikipedia.org addresses redirect by default to en.wikipedia.org and light mode, but i have sometimes edited the web address to en.m.wikipedia.org to get the mobile dark mode on my laptop.
Today (Saturday July 27) on my laptop, en.wikipedia.org (i think it was en.wikipedia.org/wiki/Wikipedia:Sandbox if that matters) gave me a pop-up alert saying something along the lines of "dark mode is available in the Appearance link of the menu on the right side of the screen" but i can't find Appearance listed in any of the five menus i've found:
The upper right of the screen has three dots resembling an ellipsis... that gives me this drop down menu:
Pages for logged out editors (learn more)
Contributions
Talk
below that is the drop down menu for languages (obviously Appearance doesn't belong there)
below that is a Tools drop down menu (i can list its options if that would help, but Appearance isn't one of them, even when i scroll down as far as it goes, so...)
The upper left has what looks like a triple bar or 三 that reveals a drop down Main menu (again, i can list the options, but Appearance isn't there, even scrolling to the bottom)
below that is the drop down table of Contents, resembling a vertical ellipsis next to a triple bar, somewhat like ⋮Ξ (again, Appearance doesn't belong there, although as a pictograph it looks like it could be a settings menu)
Appearance is also not visibly part of the footer "menu":
Privacy policy
About Wikipedia
Disclaimers
Contact Wikipedia
Code of Conduct
Developers
Statistics
Cookie statement
Mobile view
i also checked Wikipedia's Main Page with similar results (no Appearance nor ⋮三).
i exited the pop-up in search of the Appearance link and have not been able to get the pop-up again (which is normally a good thing, but right now means i can't double check anything about it, like, "did it say Appearance or appearances?")
If anyone knows what's going on here, please don't leave me in the dark. i mean, let me in on the dark. You know what i mean. ;-)
Usually the start discussion notice is displayed on talk pages with no comments; But, now its in all talk pages. Even in Wikipedia talk:Village pump (technical), Don't know how long it has been but I just noticed it. Is it a glitch or something??? Vestrian24Bio (TALK) 11:48, 26 July 2024 (UTC)[reply]
The current and prior templates need to be merged into a catchall so we can have a percentage if we want but also have no percentage for many articles. I could simply make two separate templates and rename them so we could use either, if that's preferred at wikipedia. or we add an attribute to the current template that adds the (72.6%) after the win loss. We use the template because so many editors forget to use an ndash instead of a hyphen. If it's better or easier to have two templates just let me know. Thanks. Fyunck(click) (talk) 19:25, 26 July 2024 (UTC)[reply]
Exploring this further... the "search the archives" function at NPOVN seems to be working fine. The problem seems to be that the "list of archives" for NPOVN appears to have been replaced with the "list of archives" for RSN. Blueboar (talk) 12:15, 27 July 2024 (UTC)[reply]
Hi all at the Pump, it's easy to feel disconnected despite the fantastic and often thankless efforts you make to keep WP going behind the scenes. I don't do barnstars, but here's a pic of a huge medieval barn instead. Well done, and thank you again for all your tireless and often unacknowledged hard work. MinorProphet (talk)— Preceding undated comment added 13:24, 27 July 2024 (UTC)[reply]
On List of Anaheim Ducks seasons, when you view the page logged out and scroll down far enough, the year by year table partially covers up the appearance settings (in Google Chrome, Windows 11, for what it's worth). I'm guessing this probably isn't intended; is there a means of nudging the settings over so they are fully visible for users? Home Lander (talk) 17:06, 27 July 2024 (UTC)[reply]
Per mw:Recommendations for mobile friendly articles on Wikimedia wikis you can mark large tables up so that they scroll (I did that for this article). This issue has been around for over a decade now for mobile users. Vector 2022 just brought the issue to a larger audience.
The referenced issue (if solved) will likely be resolved by marking up tables like this automatically but I don't think there is a silver bullet for fixing every table (this solution is incompatible with sticky headers for example). 🐸Jdlrobson (talk) 02:24, 28 July 2024 (UTC)[reply]
I am not sure if this is the right forum. Feel free to move it to a proper one, such as WP:Village pump (idea lab).
When page A needs to be renamed to B, but B redirects to A, what commonly happens is that B gets moved to C without leaving a redirect (so that page B is free), meaning A can then be renamed to B, and C can be renamed to B, also without leaving a redirect. This is called a round robin move. Alternatively, the redirect B can simply be deleted. Since this is commonly done, is it feasibility and technically possible to do the two moves at the same time (eg, A to B and B to A at the same time), removing the need for a third one? JuniperChill (talk) 19:35, 27 July 2024 (UTC)[reply]
The UK Space Agency article has a logo at the top which is supposed to have the red, blue and white colors of the union jack, however the image doesn't actually use white, it uses transparent so it blends in with the off-white panel. However in dark mode the transparent area appears black so the logo appears red, blue and black which is wrong. The solution would be for images not to use transparent colors when they should be white although this would upset people who want the image to blend in with the off-white background panel. Termynaytor (talk) 04:45, 28 July 2024 (UTC)[reply]
Agreed. If a logo is truly intended to be transparent background, we should use that, of course. But that is the rarity. I'm not one for "catering" to companies/organizations' preference, but in the display of their logos (whether it's a white background or otherwise) we should follow their press/media kits for displaying it - at least in the color department. The vast majority of organizations will have their logo as part of a press/media kit with guidance on how it is to be shaped, the colors to use (often with exact hex values) - and we should use logo images that comply with those even if they are public domain, in my opinion. -bɜ:ʳkənhɪmez (User/say hi!) 05:23, 28 July 2024 (UTC)[reply]
@Termynaytor: SVG files are comparatively easy to edit, especially when they were not created with InkScape. Use a plain text editor such as WordPad. This SVG image had just three elements - the <svg>...</svg> element itself, plus one <path /> element each for the red and blue portions. There is nothing to specify either background or transparency - SVG images are implicitly transparent, except for those areas where an object has been drawn that is 100% opaque.
I've added a fourth element, being <rectx="0"y="0"width="500"height="140"fill="white"stroke="none"/> which draws a white background before the coloured bits.
Thanks for that. There are other images in the thread linked by WOSlinker above such as the Porsche and Apple logos but people might prefer to keep the transparency in those cases. Termynaytor (talk) 08:42, 28 July 2024 (UTC)[reply]
Dark Mode doing strange things to Page History on pages where Pending Changes is active
This page has WP:Pending changes activated. The edit history listing now looks odd when Dark mode is activated. On edits that have been accepted, that line has a white background instead of black/dark and the text is light-colored, making it more hard to read. Instead, this should be a dark grey background, lighter than the standard background, so as to fit with the dark scheme, and make the text readable.
There's this recurring issue at Special:WantedCategories where a redlinked Category:Clean-up categories from YYYY gets generated because somebody has erroneously backdated a maintenance template to 15 or 20 years ago — following which a bot automatically recreates the resulting redlinked maintenance-queue category for that specific template, but then leaves the general "clean-up" container as a redlink that ends up becoming the category cleanup crew's job to fix.
For example, Category:Articles with unsourced statements from July 2004 has been recreated four times within the past two weeks, just from people accidentally typing 2004 instead of 2024 in a {{citation needed}} template somewhere in an article, which is obviously just a disruptive pain in the badonkadonk to have to keep dealing with over and over.
I've asked here before, and was told that it was possible, but obviously it didn't happen: is there any way that maintenance templates like {{citation needed}} can be made to do an ifexist check on categories, and file nonexisters in an error-catcher category (e.g. "citation needed with dating problems" or something along those lines) instead of causing the recreation of a redlinked category that's already been cleaned up and deleted in the past? Bearcat (talk) 13:21, 28 July 2024 (UTC)[reply]
Also, given that it's clearly possible for bots to detect and automatically create redlinked maintenance categories as needed, then can any of the following things that inevitably hit WantedCategories on a regular basis get farmed out to bots instead of becoming my job to fix?
"Wikipedia Today's featured article nominations from [Current Month and Year]", which consistently lands there at some point in the middle of every month without fail, and should really just be automatically created by a bot right off the top of the month if it's routinely expected to exist?
Any non-empty redlinks of the "Articles containing [Insert Language Here] text", "Pages with [Insert Language Here] IPA" and "CS1 [Insert Language Here]-language sources (lang code)" varieties?
Dated maintenance categories (such as Category:Articles with unsourced statements from July 2024) are created by AnomieBOT (talk·contribs) if either of two conditions apply: (i) it's now the last day of the preceding month; (ii) there's a page in the category and the date is valid - even if the year is a typo. I would expect that if you want different behaviour from AnomieBOT, your first contact should be Anomie (talk·contribs), who (unlike some botops I could name) is not only active but also replies to talk page messages.
At Great Britain at the Olympics the sections are not collapsible as expected on the mobile interface. In my sandbox I tried removing sections until it worked again, then reinstating that section and removing everything else, only to find that it worked again. I also tried fixing the markup errors (specifically, invalid HTML attributes) but that didn't fix it either. So I can only assume the cause is the "Medals by sport" section just being excessively large. Is this a known limitation of the collapsing mechanism? Should that section be split up so the collapsing works? Hairy Dude (talk) 16:49, 28 July 2024 (UTC)[reply]
The three linked "related articles" at the bottom of each article page are showing their thumbnails in photographic negative for me. A temporary glitch, a problem on my end (mobile android chrome), I don't know -- standard images in-article look fine. I wanted to let someone know in case there is an issue to fix. See, e.g., bottom of Thomas Cromwell or Wyatt's rebellion. Al Begamut (talk) 17:04, 28 July 2024 (UTC)[reply]
Courtesy link: Wikipedia:Copying text from other sources § Can I copy from open license or public domain sources?
Works for me, and please see Wikipedia:Village pump (technical)/Archive 213#The time allocated for running scripts has expired. --Redrose64 🌹 (talk) 18:15, 23 July 2024 (UTC)
Vestrian24Bio (TALK) 17:22, 26 July 2024 (UTC)
Done It wasn't. Just fixed it. •Shawnqual• 📚 • 💭 00:21, 27 July 2024 (UTC)
.png){kind=link}
You are invited to join the discussion at Template talk:Hidden archive top § Heading text colour unreadable in dark mode. Rummskartoffel 10:53, 28 July 2024 (UTC)