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.
Facing a new issue today regarding the IP Information Tool where access to some of the non-admin information does not show up in the Special:Contributions page for an IP as it did before. That page now only shows "Version", "Active blocks", and "Contributions". Oddly, the country (not city) location still pops up on the watchlist preview, even though it does not show on the Contributions page. Anyone else seeing similar? Best, CMD (talk) 08:00, 15 May 2024 (UTC)[reply]
The IP information drop down has been returning no information for me other than the version (IPv4 vs. IPv6), local block info and contribs for the last two days. It's like it can't access any of the data from whichever database it draws from. Every other field simply states "not available".-- Ponyobons mots21:43, 15 May 2024 (UTC)[reply]
And regarding my odd note on watchlist preview, this only happens sometimes, with even different edits from the same IP showing me country location in one instance but not another. CMD (talk) 01:50, 16 May 2024 (UTC)[reply]
Further learning, I can refresh the same IP contributions page repeatedly and sometimes it will show me the country, sometimes it will show no access. CMD (talk) 03:25, 16 May 2024 (UTC)[reply]
Thanks, I'm able to reproduce. According to https://phabricator.wikimedia.org/T363118#9804312, "not available" is case #2. This means Spur/Maxmind doesn't have that data. Looking at these fields, they're all populated by Spur. Maxmind and Spur have different coverage, so we may have a location for an IP but no other data for it.. So that one is not a bug and they have no plans to patch it, it looks like. –Novem Linguae (talk) 15:56, 16 May 2024 (UTC)[reply]
I don't understand how that data was available consistently for all IPs, then suddenly is missing for nearly all of them. It renders the entire IP contribs drop down useless. Oh well.-- Ponyobons mots16:13, 16 May 2024 (UTC)[reply]
Someone just commented in the ticket that they think it's happening way more than it used to and they think something is broken. So it may be a bug after all. Here's hoping the devs figure it out. –Novem Linguae (talk) 16:47, 16 May 2024 (UTC)[reply]
If I refresh sometimes, sometimes, the location info magically just appears. So the data is there. Sometimes. This is all on the same IP page. The one listed just above if I refresh does show the location 1 time out of 4 or so. Canterbury Tailtalk15:58, 21 May 2024 (UTC)[reply]
Dark mode is available in Vector 2022 as a beta feature
Show what we've built very early. The earlier you are involved, the more your voices will be reflected in the final version
Get your help with flagging bugs, issues, and requests
Work with technical editors to adjust various templates and gadgets to the dark mode
Known limitations
Dark mode is only available for logged-in users: on desktop as a beta feature, and on mobile in the advanced mode.
Gadgets may initially not work well with dark mode and may have to be updated.
Our first goal is making dark mode work on articles. Special pages, talk pages, and other namespaces (including Wikipedia) have not been updated to work in dark mode yet. We have temporarily disabled dark mode on some of these pages.
What we would like you to do
Our request to you is exactly the same as previously:
I don't know if this was the right move. Tons of pages still look like garbage (shoutout Special:Watchlist)—the theme is definitely not ready for use by non-technical editors. It wouldn't be too bad if you had made a seperate beta option for it—because you've clumped it in with Accessibility for Reading a couple people have gone on the Discord confused. Snowmanonahoe (talk·contribs·typos) 23:54, 15 May 2024 (UTC)[reply]
"Fixing" it is as simple as setting your personal chosen theme to light mode.
As for tons of pages, I just got separate word that OOUI interfaces don't support light mode (currently/ever?), which is why Watchlist has light elements. Perhaps it shouldn't be displaying as dark. Izno (talk) 00:08, 16 May 2024 (UTC)[reply]
The point is for editors to find these things. Might as well drop logged users in and let them make the two button presses to find a different, less-painful choice. Izno (talk) 00:41, 16 May 2024 (UTC)[reply]
Exactly, there is no magic fairy dust for some of this, just grunt work to fix the pages and templates that never had to account for a darkmode. —TheDJ (talk • contribs) 14:56, 16 May 2024 (UTC)[reply]
We do have a long-term solution for OOUI fixes that is in development right now. We hope to have it ready within the next couple of weeks. In the meantime however, pages like Watchlist and should be displaying in light mode so this is a bug. We're tracking it in phab:T365084 and should have a fix out later today. OVasileva (WMF) (talk) 07:36, 16 May 2024 (UTC)[reply]
@SGrabarczuk (WMF): Is there really a plan to take over the right 1/4 of screen with a "settings" panel every time someone opens a page in a new private tab, or clears cookies, or switches to a new language, or doesn't realize what the "hide" button does? Or is that just so in-your-face during the testing phase? Suffusion of Yellow (talk) 02:01, 16 May 2024 (UTC)[reply]
Hey @Suffusion of Yellow - thanks for the question. In general, we think this is the most effective way to launch the new menu and be able to inform users about it. It removes the necessity to add additional modals or notices that say "New menu available!" or "Dark mode available", which would otherwise show on every pageview. So, the current plan is to keep the menu open by default for the wider release as well for all logged-in and logged-out users. Then, after the release, we can look at the data to gauge whether we need to keep it open as default, or collapse, and when. OVasileva (WMF) (talk) 07:40, 16 May 2024 (UTC)[reply]
Why can't it be on the left side, with the TOC? Or better yet, just put a plain-text link at the top? I mean, registered users have already been able to find the "preferences" link for 20 years now. Right when I open up testwiki:LOREM IPSUM (or any page with a TOC) on my phone in a new private tab, then switch to the desktop site, about half my screen is whitespace, and the text is squished into a narrow little strip in the middle. It's unusable until I hide the settings column
People are reading a website, not installing software. There shouldn't be a "setup" stage before they can get down to the business of looking up that one little fact. The defaults should at least be usable. Suffusion of Yellow (talk) 17:11, 16 May 2024 (UTC)[reply]
Hi @Suffusion of Yellow - we generally have most personalized tools (page tools, the user menu, preferences) on the right side of the page, which is why we chose this location. It would have been confusing to show a menu on the left side of the page, next to the content-related ToC, only to then collapse it into the right side. Hope that makes sense.
In terms of the defaults - I couldn't agree with you more. We want our defaults to be as usable as possible (and also to provide an easy opportunity for customization). We are currently in the process of defining and setting defaults for all three areas in the menu. These default will become available as the features themselves are ready. For example, the default for dark mode will be "automatic", which will follow the user's device settings. OVasileva (WMF) (talk) 06:46, 21 May 2024 (UTC)[reply]
@SGrabarczuk (WMF):https://night-mode-checker.wmcloud.org/ appears to only be for the mobile version. Is there is desktop report? Also, the beta is only for Vector 2022. Many editors still use legacy vector or other skins, will the new feature be moved to any other skin besides Vector 2022? How does the new feature compare to the dark mode gadget that is currently available? RudolfRed (talk) 03:31, 16 May 2024 (UTC)[reply]
Hi. One of my pastimes is trying to empty Category:Harv and Sfn no-target errors. Today I found Military courts of the United Kingdom, which has multiple uses of {{sfn|Armed Forces Act|2006}} which are meant to link to {{UK-LEG|title=Armed Forces Act 2006|path=ukpga/2006/52 |ref={{harvid|Armed Forces Act|2006}}}} but don't. I can't work out how to fix the no-target errors and get the link from sfn to citation template to work. Any help will be appreciated, thank you. DuncanHill (talk) 10:22, 16 May 2024 (UTC)[reply]
{{UK-LEG}} does not know about |ref= so does not create an anchor ID. Without an anchor ID, {{sfn}} has nothing to link to. Your options are to modify {{UK-LEG}} or implement an appropriate solution from the list of possible solutions at :Category:Harv and Sfn template errors § Resolving errors: {{wikicite}} (best) or {{anchor}} (not so best).
ChristieBot, which manages GA nominations, has been crashing when trying to transclude the GA review to Talk:Israeli invasion of the Gaza Strip (2023–present). The error is "Page en:Special:Log is not supported due to namespace restriction". The page is extended-confirmed protected. The bot does have extended-confirmed rights as part of the bot group rights, but presumably is missing some other related permission. I can change the code to not crash and simply log the error, but I'm at work and won't be able to touch the code for a few hours. If anyone can tell me what the problem is I would appreciate it. Thanks. Mike Christie (talk - contribs - library) 12:48, 16 May 2024 (UTC)[reply]
Is this something I can set myself, and if so, where? (I'm not an admin.) I thought that a bot just needed the same user rights as a non-bot editor would need to edit a given page. Mike Christie (talk - contribs - library) 13:46, 16 May 2024 (UTC)[reply]
I don't have access to toolforge from where I am now, and since it was set up eighteen months ago I don't recall the details offhand, but as I recall I have a config set up in the toolforge shell account that handles the bot authentication. I think that means it uses BotPasswords? Mike Christie (talk - contribs - library) 14:04, 16 May 2024 (UTC)[reply]
@Mike Christie You'd have to check your PyWikiBot user-config.py file. If it has an authenticate[] = line you're using oauth, if it has a password_file = line you're using BotPasswords. --Ahecht (TALK PAGE)14:08, 16 May 2024 (UTC)[reply]
I don't recall getting oauth to work so I think it must be BotPasswords, which I remember dealing with. (If SD0001 is available and has a moment they may be able to look and confirm as they are a maintainer for that bot.) Mike Christie (talk - contribs - library) 14:19, 16 May 2024 (UTC)[reply]
It's using BotPassword. It should be able to edit the page if the appropriate grant is checked as mentioned above. But from the error message, I am wondering if there is a code issue as well - the bot seems to be literally trying to edit Special:Log which of course isn't possible. – SD0001 (talk) 17:58, 16 May 2024 (UTC)[reply]
That flag is now checked but it hasn't fixed the issue. The issue only occurs when trying to edit that page, using the same code that it uses for transcluding GA reviews on other talk pages, so I can't see why Special:Log is in the picture. There's certainly no explicit attempt by the bot to try to edit the special page. The error happens when it attempts to add text to the Page object's text field: in the traceback I see self.botMayEdit() is called, in pywikibot/page/_basepage.py, which eventually pops out to the Special:Log error for some reason. Later I will have time to add some code to trap the error so at least it'll finish its run, even if it can't do that particular transclusion. I'll do that this evening unless someone has any further ideas. Thanks for the help so far. Mike Christie (talk - contribs - library) 19:04, 16 May 2024 (UTC)[reply]
This appears to be an error in pywikibot, I can confirm it also occurs for me.
Full traceback
--------------------------------------------------------------------------- UnsupportedPageError Traceback (most recent call last) Cell In[1], line 4 2 site = pywikibot.Site('wikipedia:en') 3 page = pywikibot.Page(site, 'Talk:Israeli invasion of the Gaza Strip (2023–present)') ----> 4 page text = 'foo' File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:576, in BasePage.text(self, value) 571 """Update the current (edited) wikitext. 572 573 :param value: New value or None 574 """ 575 try: --> 576 self.botMayEdit() # T262136, T267770 577 except Exception as e: 578 # dry tests aren't able to make an API call 579 # but are rejected by an Exception; ignore it then. 580 if not str(e).startswith('DryRequest rejecting request:'): File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:1146, in BasePage.botMayEdit(self) 1131 """ 1132 Determine whether the active bot is allowed to edit the page. 1133 (...) 1143 user cnfig file (user-config.py), or using page.put(force=True). 1144 """ 1145 if not hasattr(self, '_bot_may_edit'): -> 1146 self _bot_may_edit = self._check_bot_may_edit() 1147 return self _bot_may_edit File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:1163, in BasePage._check_bot_may_edit(self, module) 1161 username = self.site.username() 1162 try: -> 1163 templates = self.templatesWithParams() 1164 except (NoPageError, IsRedirectPageError, SectionError): 1165 return True File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_page.py:78, in Page.templatesWithParams(self) 62 """Return templates used on this Page. 63 64 The templates are extracted by :meth:`raw_extracted_templates`, (...) 74 :rtype: list of (pywikibot.page.Page, list) 75 """ 76 # WARNING: may not return all templates used in particularly 77 # intricate cases such as template substitution ---> 78 titles = {t.title() for t in self.templates()} 79 templates = self raw_extracted_templates 80 # backwards-compatibility: convert the dict returned as the second 81 # element into a list in the format used by old scripts File /srv/paws/lib/python3.10/site-packages/pywikibot/page/_basepage.py:1612, in BasePage.templates(self, content) 1609 del self _templates 1611 if not hasattr(self, '_templates'): -> 1612 self _templates = set(self.itertemplates(content=content)) 1614 return list(self._templates) File /usr/lib/python3.10/_collections_abc.py:330, in Generator.__next__(self) 326 def __next__(self): 327 """Return the next item from the generator. 328 When exhausted, raise StopIteration. 329 """ --> 330 return self.send(None) File /srv/paws/lib/python3.10/site-packages/pywikibot/tools/collections.py:279, in GeneratorWrapper.send(self, value) 276 if not hasattr(self, '_started_gen'): 277 # start the generator 278 self _started_gen = self generator --> 279 return next(self._started_gen) File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:625, in QueryGenerator.generator(self) 622 self normalized = {} 624 try: --> 625 yield from self._extract_results(resultdata) 626 except RuntimeError: 627 break File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:567, in QueryGenerator._extract_results(self, resultdata) 565 """Extract results from resultdata.""" 566 for item in resultdata: --> 567 result = self.result(item) 568 if self _namespaces and not self._check_result_namespace(result): 569 continue File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:736, in PageGenerator.result(self, pagedata) 734 elif ns == Namespace.CATEGORY: 735 p = pywikibot.Category(p) --> 736 update_page(p, pagedata, self.props) 737 return p File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:983, in update_page(page, pagedict, props) 966 def update_page(page: pywikibot Page, 967 pagedict: dict[str, Any], 968 props: Iterable[str] | None = None) -> None: 969 """ 970 Update attributes of Page object *page*, based on query data in *pagedict*. 971 (...) 981 supported yet 982 """ --> 983 _update_pageid(page, pagedict) 984 _update_contentmodel(page, pagedict) 986 props = props or [] File /srv/paws/lib/python3.10/site-packages/pywikibot/data/api/_generators.py:882, in _update_pageid(page, pagedict) 880 raise InvalidTitleError(f"{page}: {pagedict['invalidreason']}") 881 if int(pagedict['ns']) < 0: --> 882 raise UnsupportedPageError(page) 883 raise RuntimeError(f"Page {pagedict['title']} has neither 'pageid'" 884 " nor 'missing' attribute") UnsupportedPageError: Page en:Special:Log is not supported due to namespace restriction.
Search results have a thumbnail next to them, or a gray placeholder if there's no suitable image in the article. Since today, those placeholders are bigger than regular thumbnails, which also places them uncomfortably close to the article text. It appears to be caused by this CSS rule:
.searchResultImage .searchResultImage-thumbnail > div {
padding: 0.5em;
}
I don't think the talk page will get the comment any light, so I am putting it here. It does not require any discussion but a confirmation from technical person that it won't cause any issue. Thanks, ExclusiveEditorNotify Me!10:51, 17 May 2024 (UTC)[reply]
Nothing you change in a "Template:XXXXXX/doc" page is going to break anything on other pages; worst case is it confuses someones that reads the documentation. — xaosfluxTalk12:49, 17 May 2024 (UTC)[reply]
Configuring Git for Gerrit
I have a sort of "hello, world" MediaWiki coding change I'd like to submit as my first-ever contribution to MediaWiki, and to get myself started and oriented with the system for submitting coding changes. If all goes well with that, I hope to follow that up with a more substantial change sometime, hopefully soon, after that. I already have a Wikimedia developer account, with accounts on MediaWiki and Wikitech. My usernames there, including my SSH access (shell) username, are the same as my English Wikipedia username. Now mw:Gerrit/Tutorial#Configure Git is telling me I need to have my "own Gerrit username". Is this a name which is unique to Gerrit, and not used anywhere else, such as the Toolforge? Also, I see on the Gerrit settings page a "Username" (is that the same as Git's "own Gerrit username"?), "Full name", and "Display name" – how are each of these used? Which of these names are used for the CREDITS page, the list that's updated by updateCredits.php? wbm1058 (talk) 20:35, 17 May 2024 (UTC)[reply]
Your Gerrit username is more properly your developer account username, which is the same as on Toolforge and other places. For those three fields, username is what you log in as, I don't think Full name is used anywhere, and display name is how your name appears on the Gerrit UI. updateCredits.php seems to parse "git log", so the name used is whatever shows up in Git, which usually is the same as one of the above but not necessarily. * Pppery *it has begun...20:52, 17 May 2024 (UTC)[reply]
Full name is actually what's used for sign-ins via web UIs (Wikitech, Toolsadmin). "Username" is only used for SSH access (toolforge / git review). The CREDITS page uses the name from git log, which you'd set through the git config --global user.name command. – SD0001 (talk) 21:22, 17 May 2024 (UTC)[reply]
Thanks. Further complicating naming matters, I see there is an "LDAP" (Lightweight Directory Access Protocol) username. See wikitech:SRE/LDAP. Per wikitech:SRE/LDAP/Renaming users, "We do not rename users (Developer accounts) anymore. It can (and has) lead to various problems and errors all over the many separate systems which consume Developer accounts as their local databases and authentication methods will get out of sync." So I guess I'm stuck for now with the name I have (not that I want to change it). But a reason for proceeding cautiously here. I don't want to stumble into doing something irreversible that I wish I'd done differently later, after I figured out what I was actually doing, rather than signing up for it by trial and error. I don't recall seeing the mw:Developer account page before, and I think I created mine before the Create a Wikimedia developer account form was created. Today I just ran into the Bitu Identity Manager, which shows me "My LDAP properties". (see wikitech:IDM). Phabricator says my LDAP User is "Unknown". I don't know if there's a way I can personally make it known, or whether it being unknown is a problem. – wbm1058 (talk) 22:14, 17 May 2024 (UTC)[reply]
I think theres basically 2 logins. #1 is the oauth / centralauth / all wikis but wikitech one. #2 is ldap / gerrit / toolforge / wikitech. Lots of synonyms here. I forget if phabricator is one of those two, or a third one. –Novem Linguae (talk) 22:26, 17 May 2024 (UTC)[reply]
I suppose Phabricator is probably bilingual. Obviously I sign into it using my #1 because my #2 is unknown to the phabulous Phabricator. On the other hand, there must be some developers using it who may not have a #1. – wbm1058 (talk) 22:43, 17 May 2024 (UTC)[reply]
Yes, phab supports sign-in via either of the two. You can still link phab with the other account through Settings > External accounts. – SD0001 (talk) 06:21, 18 May 2024 (UTC)[reply]
Facepalm I looked at that screen twice and all I saw was date & time settings! Thanks! Now my account is linked with all (two) available providers. – wbm1058 (talk) 10:45, 18 May 2024 (UTC)[reply]
When asked why he called the new software, 'git', British slang meaning 'a rotten person', Torvalds said 'I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git.' Ha! wbm1058 (talk) 12:00, 18 May 2024 (UTC)[reply]
More from the "I figured out what was happening only after it already happened" department. Wikimedia Code Reviewhttps://gerrit.wikimedia.org/r/settings says I registered @ Monday, May 13, 2024, 9:08:55 PM UTC-04:00 ... what? I don't recall doing anything specific to "register" there last Monday. What was I doing at that time? I thought per mw:Gerrit/Tutorial I had to configure Git in order to register for Gerrit, but here I am already registered for Gerrit, and I haven't configured Git yet! O I C. I think I was looking at a previous code review related to the task I'd decided to work on, when I noticed "Sign up" and "Sign in" links on the upper right corner of that page. Clicking "Sign up" took me to this new IDM "Create account" page to create a Wikimedia developer account. Hey, I thought, I think I already have one of those that I needed for Wikitech/Toolforge. So I left that page, and clicked "Sign in". Voila, my Wikitech password got me in. I thought I had simply logged into Gerrit, not registered for it. What I didn't realize was that the "Bitu Identity Manager" would not only sign me in, but register me as well! wbm1058 (talk) 16:12, 18 May 2024 (UTC)[reply]
SSH keys
I already have SSH keys set up for Toolforge at Toolsadmin which I use on PuTTY and WinSCP but not directly from the Windows command prompt.
mw:SSH keys seems to indicate that I can't use my Toolsadmin SSH but will need another one, set up from the Windows command prompt. Correct?
Also, regarding configuring Git personal information. The guide says "You should have to do this only once." Is that literally true, or does it mean once on my desktop and once on my laptop, if I have two machines that I might want to submit code from? wbm1058 (talk) 18:06, 18 May 2024 (UTC)[reply]
@Wbm1058 You can reuse the same SSH key across multiple projects (in this case toolsadmin and Gerrit). The tutorial assumes that you have not setup the keys before.
My desktop is still running Windows 7. I know, I know, long in the tooth, but I'm proud to have kept it going for 14 years and would like to make it to 15. It still works for me, for the most part. I've downloaded the production version MediaWiki 1.41.1 and have it running for debugging. I generated my SSH keys with PuTTYgen, since the Windows 7 command prompt does not support the ssh command. I suppose I'd need to use PuTTY on that machine to connect to Gerrit, as I use it to connect to the Toolforge bastion. I think I can figure that out; haven't found documentation on how to use Gerrit on a Windows 7 machine. I haven't set up SSH on my Windows 10 laptop yet (only do Toolforge from my desktop). I don't know how to copy my keys from PuTTY to the required location on Windows 10. Might be easier to generate new keys on Windows 10. I have an ssh-rsa key for Toolforge access; the documentation says to use the ed25519 type for optimum security and performance. Can I use different SSH keys on each machine? wbm1058 (talk) 16:53, 19 May 2024 (UTC)[reply]
As a matter of fact, you are kind of expected to use different keys per user per machine. That’s why all the ssh settings of toolforge and Gerrit allow you to add multiple public keys. —TheDJ (talk • contribs) 16:58, 19 May 2024 (UTC)[reply]
What TheDJ said, you are expected different SSH keys across machines. However, if you are using one machine, you can reuse the key across multiple things (I have mine on Github/Gitlab/Toolforge and Gerrit as well as a bunch of private services). Sohom (talk) 18:15, 19 May 2024 (UTC)[reply]
OK, thanks! New state-of-the-art ed25519 keys generated and installed for my Windows 10 laptop (which MSFT tells me will be unsupported after next year, and my hardware is too old to run Windows 11(.
"This clones the entire MediaWiki core repository, synced to the master branch, into a sub-directory named mediawiki"
I previously installed MediaWiki 1.40.1 on my laptop last November at the Toronto wikiconference, by downloading the then-current version from mw:Download, and successfully installed that, for testing.
I want to overwrite my previous 1.40.1 installation with the new files I just git got.
The standard mediawiki directory holds core and data sub-directories.
It doesn't appear that the git download includes any data. It appears to be a core directory, which includes some extra files that aren't part of the mw:Download version. Why don't the instructions say to download to a sub-directory named core rather than a sub-directory named mediawiki?
If using Git, export the files into a clean location, and then copy the old customized files into the new location as described in the previous section.
You will also need to install some external PHP libraries using Composer or a provided collection maintained for the Wikimedia wiki farm. More details on installing and updating external libraries can be found in the Git download documentation
So, for some reason, although I can test using 1.40.1 without having any PHP problems, I'll need to figure out this "Composer" thing in order to do development testing.
I think all mediawiki unit tests are passing on php 8.1. Not sure about php 8.2. May want to switch to 8.1 to prevent hard to diagnose bugs. –Novem Linguae (talk) 00:45, 20 May 2024 (UTC)[reply]
mw:Manual:Installation requirements#PHP does not mention "Composer". It says "MediaWiki only requires PHP extensions that are enabled in PHP by default." I assume that's why I didn't get this error when I ran update.php on my desktop, where I'm just running the official MediaWiki releases. "If your hosting provider provides a basic LAMP environment without these, you may need to install or enable these manually."
I don't think submodules is what you need. The php maintenance/run.php update.php script just wants you to composer install in the mediawiki directory, that should download the required directories. Sohom (talk) 14:34, 20 May 2024 (UTC)[reply]
c:\php\mediawiki>composer update --no-dev
Composer could not find a composer.json file in c:\php\mediawiki
To initialize a project, please create a composer.json file. See https://getcomposer.org/basic-usage
Judging by your previous comments, you're just not in the directory that Composer expects – try going to c:\php\mediawiki\core, where you (and Composer) should find the composer.json file. Matma Rextalk16:09, 20 May 2024 (UTC)[reply]
Yes, thanks, that was it. Once again the instructions misled me: "then run composer update --no-dev from your MediaWiki core directory." It's still running. This step takes significant time! wbm1058 (talk) 16:20, 20 May 2024 (UTC)[reply]
I think it worked. The console log is long, with a pile of "failed to download" warning messages, but it appears to have successfully worked around all of them. Here's the end of the log, showing just the last 3 of many installations:
- Installing wikimedia/timestamp (v4.1.1): Cloning 138f3099b4 from cache
- Installing wikimedia/xmp-reader (0.9.1): Cloning 8338d67969 from cache
- Installing zordius/lightncandy (v1.2.6): Cloning b451f73e8b from cache
44 package suggestions were added by new dependencies, use `composer suggest` to see details.
Generating optimized autoload files
11 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> MediaWiki\Composer\ComposerVendorHtaccessCreator::onEvent
No security vulnerability advisories found.
c:\php\mediawiki\core>php maintenance/run.php update.php
Error: The MinervaNeue skin cannot be loaded. Check that all of its files are installed properly.
PHP Fatal error: Error Loading extension. Unable to open file C:\php\mediawiki\core/skins/MinervaNeue/skin.json: filemtime(): stat failed for C:\php\mediawiki\core/skins/MinervaNeue/skin.json in C:\php\mediawiki\core\includes\registration\MissingExtensionException.php on line 96
Fatal error: Error Loading extension. Unable to open file C:\php\mediawiki\core/skins/MinervaNeue/skin.json: filemtime(): stat failed for C:\php\mediawiki\core/skins/MinervaNeue/skin.json in C:\php\mediawiki\core\includes\registration\MissingExtensionException.php on line 96
Sigh. I didn't need no extensions when testing changes to the official release core page-moving functions. Now I do. – wbm1058 (talk) 18:04, 20 May 2024 (UTC)[reply]
You shouldn't need any extensions to run MediaWiki core. It's only trying to load the MinervaNeue skin, because you have a line in your LocalSettings.php like wfLoadSkin('MinervaNeue'); (maybe you copied it from your previous installation?). You can remove it or comment it out if you don't want it.
If you do want it, then you can install the skin using Git similarly to how you installed MediaWiki, just replacing the path in the git clone command: instead of mediawiki/core, use mediawiki/skins/MinervaNeue (and make sure to put it in the skins directory, where MediaWiki is looking for it). Similarly for all other skins and extensions. Matma Rextalk18:13, 20 May 2024 (UTC)[reply]
Thanks! I just used the default LocalSettings.php that came with the release-version installation. Figuring I only need one skin, I just copied the folder from my backup of the release version, and commented out the others. That did the trick, and the database update looks like it ran successfully. – wbm1058 (talk) 20:28, 20 May 2024 (UTC)[reply]
MediaWiki internal error.
Original exception: [6d2f7f0574eb09bb447c9687] /index.php/Main_Page Error: Class "ResourceLoaderSkinModule" not found
Backtrace:
from C:\php\mediawiki\core\includes\ResourceLoader\ResourceLoader.php(417)
The ResourceLoaderSkinModule class was recently renamed (gerrit:994854). It seems that you've just updated your MediaWiki to a version that doesn't have it any more, but one of your skins is an older version that is still using it. This will occasionally happen with skins and extensions.
If you've already installed the skin from Git, running git pull in the affected skin's repository should fix it. If you haven't, it's probably best if you do :) but you can also remove it from LocalSettings.php, or download the latest master snapshot from SkinDistributor/ExtensionDistributor. Matma Rextalk21:51, 20 May 2024 (UTC)[reply]
Done. Success. I have a development environment which seems to be operating identically with the official-release environment I just replaced. Tomorrow I move to the next step. Make minor "hello, world!" type changes in two files, and then figure out how to submit them for review. FYI, the project I'm working on, where I hope to make more substantial enhancements soon, is discussed on my talk: User talk:Wbm1058#My MediaWiki core developers thread. – wbm1058 (talk) 01:40, 21 May 2024 (UTC)[reply]
mw:Local development quickstart
It's just that the way you have cloned the repo is unconventional. mediawiki/core should be cloned to a directory named "mediawiki", not "core". I think you will have a lot easier time going through mw:Local development quickstart instead, which unfortunately isn't advertised more prominently. You may want to discard the existing mediawiki install and use the quick start. You have already done step 1, so start with step 2. It's easy! – SD0001 (talk) 16:40, 20 May 2024 (UTC)[reply]
That "quick start" page has stuff I've already done previously, and insufficient info about stuff I needed to do.
I've had an "official release" version installed on my laptop since November. It makes a lot of sense to me to have started that way, because as complicated as installing the official release was, installing the developers' version is way more complicated yet.
I've had PHP installed directly on Windows for over a decade now. My bots use that.
There was no need for me to update my php.ini file to load the required PHP extensions. I already did that a long time ago. The problem is that this "composer" system basically "ignores" that, it seems to me.
It just says to "use Git" to clone the core, as if that's easy. No it wasn't. See above for what steps I went through to figure it out.
I installed SQLite already last year; I don't need to do that again.
I already knew how to start my server, though I was told by someone to use "localhost:80" in Boston in 2019, not "localhost:4000". I don't know whether it matters which number I use there.
What I need is a "quickstart" page for upgrading from an "official release" version to the developers' version. – wbm1058 (talk) 17:28, 20 May 2024 (UTC)[reply]
1 and 2. yes I said as much - you have already done step 1. 3. There's no need to configure git before cloning repos. The steps from mw:Gerrit/Tutorial#Configure_Git are only to prepare for pushing changes. 4. composer mw-install:sqlite is not for installing sqlite (not required). Instead it initialises MediaWiki itself with sqlite as the db backend. This is a shortcut to avoid going through the web installer. 5. Running something on port 80 is only advisable on linux. On Windows/macOS, it's better to use a non-reserved port (> 1023) to avoid issues with firewalls. What I need is a "quickstart" page for upgrading from an "official release" version to the developers' version. The easiest way to do that is to delete or forget about the release version and setup the developers' version from scratch. – SD0001 (talk) 17:56, 20 May 2024 (UTC)[reply]
What I did need to do before cloning was download and install Git, and setup SSH to use it. None of that was necessary to download and install the release version, which makes installing the release version an easier task.
Oh I see. a shortcut to avoid going through the web installer... well, now I know. I was wondering how that was done. But now, water under the bridge. I'd like to keep the database I started last year, for sentimental reasons, and just upgrade. I think upgrading should be easier than installing from scratch every time.
I've noted that my server runs really slowly on my system. Wrote that off as bloatware overwhelming my 14-year old processor, but, now that you mention it, could be a symptom of firewall intervention. I'll switch to port 4000 and see whether that runs faster.
It looks like the directory where git-review got installed is not in your %PATH% environment variable. First of all, try closing the command-line window and opening it again, and retry – maybe it is just seeing outdated env variables.
If that doesn't help, you'll need to change that env variable, the option to do that is somewhere in your operating system settings. Add the directory where git-review is, probably something like like C:/Python310/Scripts/ (that's where it is on my machine). Note that you need to open a new command-line window every time for the changes to take effect when testing.
(If I recall, there's a checkbox to do that automatically when you install Python, which you may have left unchecked. You can also try reinstalling Python and finding that checkbox.) Matma Rextalk15:04, 21 May 2024 (UTC)[reply]
Yes, I checked the box on the Python installation. Closing my command window and opening a new one did the trick, of course. The instructions could explicitly say to do that. Thanks again for all your help – wbm1058 (talk) 15:20, 21 May 2024 (UTC)[reply]
That directory has a .gitreview file in it, with the following content:
The instructions are probably outdated and everything is probably okay. git-review is being somewhat actively developed, and the example output in mw:Gerrit/Tutorial#Setting_up_git-review has a 2019 date. If it didn't work, you'll find out later if you get an error complaining about a missing Change-Id line. Matma Rextalk20:57, 21 May 2024 (UTC)[reply]
I don't know whether that's a problem or not, but I proceeded as if it wasn't.
Successfully rebased and updated refs/heads/T12814-hello.
c:\php\mediawiki\core>git review -R
wbm1058@gerrit.wikimedia.org: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
If you get a Permission denied (publickey). fatal: Could not read from remote repository., review the instructions at mw:SSH keys#Add SSH Private key to use with Git to make sure your ssh agent is running and your identity is added. If you close your Git Bash shell, you will be signed out and need to re-follow these instructions each time.
c:\php\mediawiki\core>eval `ssh-agent`
'eval' is not recognized as an internal or external command,
operable program or batch file.
Is there a way to run git bash from the Windows cmd prompt?
I haven't seen this exact error before, and your setup is rather different from mine, so this is a guess, but: the eval `ssh-agent` command actually works by setting environment variables, which everything else on your system can read to access the SSH agent. Maybe you just need to close and reopen the command prompt window again, so that it sees the new env variables? Matma Rextalk21:02, 21 May 2024 (UTC)[reply]
"Is there a way to run git bash from the Windows cmd prompt?" You can run something like "C:\Program Files\Git\usr\bin\bash.exe" from the command prompt, and it will run, but this is unlikely to do anything good. It will probably be confused about text encodings, file paths, and ANSI escape codes. (On Windows 10, they're slightly less incompatible.) Can you say why you want to do it? Matma Rextalk21:15, 21 May 2024 (UTC)[reply]
(edit conflict) I just tried doing it from my git bash window instead of command prompt...
I Can't edit the Main Talk page so I'm posting here.
The main page (and it's talk page) seems to be stuck in full width mode even when I click on the full width toggle button in the bottom right corner. Other pages seem unaffected.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0
In the Vector 2022 skin, main pages will be displayed at full width (like special pages). The goal is to keep the number of characters per line large enough. This is related to the coming changes to typography in Vector 2022. Learn more. [2]– robertsky (talk) 06:00, 18 May 2024 (UTC)[reply]
Need help fixing the "second" sticky row in this table. With rowspan used in the first column, only the first row in rowgroup is sticky, the rest of the rows in individual rowgroups aren't. I assume it is a "sticky-col2" issue from Template:COVID-19 pandemic data/styles.css. Can it be fixed so it displays all rows in the second column unbroken when horizontally scrolling? Qwerty284651 (talk) 19:04, 18 May 2024 (UTC)[reply]
Native Dark Mode Message
I have been using the dark mode gadget for a while now and I quite like it. I tried the native dark mode but I do not like it that much, as it is quite buggy and has a fair few contrast issues, see the phab board. Every time I load a page in namespaces outside of article space I get the message that informs me that I have two dark modes enabled and I need to choose one. When I go to disable the non-gadget dark mode it is not able to be disabled, are there any scripts to suppress this message, it is getting quite annoying. Thanks, v/r - Seawolf35T--C00:03, 19 May 2024 (UTC)[reply]
I use this search query to see pages tagged for speedy deletion. For several days it has returned BBL Drizzy as a result even though that page is not tagged for deletion. The search results say it was last edited at 01:12 on 13 May 2024, which corresponds with Special:Diff/1223572833 (now in the history of Draft:BBL Drizzy). Purging or null-editing either the article or the draft will make it disappear from the results temporarily, but so far it's always come back shortly thereafter. Today I tried deleting and undeleting the pages, but this didn't help either. Any suggestions? (This query brings up strange results too, for what it's worth.) Extraordinary Writ (talk) 03:01, 19 May 2024 (UTC)[reply]
I don't experience this. BBL Drizzy is not a result for the first query, and the last query only brings up BBL Drizzy (last edited 19:04, 18 May 2024). – 2804:F1...7F:938A (talk) 03:15, 19 May 2024 (UTC)[reply]
I've been seeing some outdated search results also related particularly to a couple page moves that got done between when the search was crafted and when my fix was made. Particularly, in this search I'm seeing Draft:Peter the Great Interrogating the Tsarevich Alexei Petrovich at Peterhof and Draft:Ellen Webster Palmer when I hit one or another of the data centers (which I assume is at least part of the problem), but at least once I've gotten a search not to return those two, because neither are drafts any longer nor do either carry the problem that makes them show up in this search. Izno (talk) 20:36, 19 May 2024 (UTC)[reply]
The Appearance menu and new default standard font size will be available for logged-out users
Hi everyone! We are the Wikimedia Foundation Web team.
We work on making it easier to read Wikimedia projects as part of the objective "Reading and media experience" of the current year’s annual plan. To achieve this goal, we have introduced the "Accessibility for Reading" beta feature. It adds a menu which works on the Vector 2022 skin and allows logged-in users to choose different font sizes and color schemes based on individual needs.
The menu introduces a new Standard font setting. It slightly increases the size and height of the font. It was selected based on multiple sources. You will find more information on this in the section "About the new Standard font setting". As we announced last week, we are now ready to begin bringing some of these feature out of beta and making them available to more people.
What will change
We are now ready to make the new Appearance menu available for logged-out and logged-in users.
At the same time, we will also make the Standard option the new default for logged-out users only.
If no breaking technical issues are found, we plan on making this change within the next three weeks.
Later, this menu will also include the option to select dark mode, which for the time being will remain a beta feature. For more information, check out our project page.
About the menu
The new menu will allow logged-in and logged-out users to set preferences for:
Text size and line height (available now as the beta feature): Users will be able to choose between the Small (current default), Standard (recommended for better accessibility), and Large options. Selecting an option will change both the font size and line height of the text.
Dark mode (available now as the beta feature): Users will be able to choose to see the site in night mode on a permanent basis, or select an "automatic" setting which will set day or night mode based on the device or browser preferences.
Content width (previously available as a toggle button): We have moved the content width toggle from an icon at the bottom of the page to a labeled radio button in the new menu. It will work exactly the same as the toggle. The previous toggle button will no longer be available.
This menu has been tested as a beta feature by logged-in users across wikis as well as in user testing with readers. Based on the findings of these tests, we changed the menu to improve discoverability and ease of use, and to accommodate gadget compatibility.
The menu will appear to the right of the page, immediately under the Tools menu if that has been pinned. Unlike the Tools menu, the Appearance menu is pinned by default, but can be unpinned. Once unpinned, it collapses under an icon at the top of the page.
About the new Standard font setting
The "Small" option is the current default. We will be changing this default to "Standard" for logged-out users, while keeping "Small" as the default for logged-in users. The "Standard" and "Large" options were built and tested based on the following:
Academic studies and recommendations for the best average font size for the majority of readers. These recommendations stated that our current size is too small for the majority of people to read comfortably. This means that on average, people read more slowly, strain their eyes while reading, or have difficulty clearly seeing the text. Increasing the font size by default improves these issues for all users, including users who might not have sufficient time to spend adjusting a setting via the appearance menu or browser. Information density is also important, which is why we wanted to increase font size without sacrificing information density. We have achieved this by changing not only font size, but also line height and paragraph spacing.
Designs submitted by more than 630 Wikipedians from across 13 wikis of different languages, scripts, and sizes. The majority (~450) of these users opted for a font size that was larger than the default. "Standard" represents the average of the most popular cluster of responses (15-20 pixels). "Large" represents the need for an even larger option, as represented by the cluster of sizes between 21-26 pixels. You can read more on how we included volunteers in the process and landed on these options.
Beta feature usage showed that the majority of users who interact with the feature at least once opt for a font size that is larger than the current default.
Our works so far and next steps
Logged-in users will remain with the "small" setting for the time being as their default, but can change to any other setting at any time. In a few months, we will study how many logged-in users switch to standard and start a conversation on whether it makes sense for logged-in users to make the switch as well. From the early data from the beta feature, 55% of sessions who interacted with the feature chose to use a setting that was standard or larger.
If you'd like to help, we have a few simple requests for you:
Try out the new menu. Is anything confusing? Do you understand all the labels and how the menu works?
Try out the small, standard, and large sizes, the color schemes, and the width toggle. Reach out to us if you notice any bugs, or have questions or concerns.
I noticed this at Aaron Swartz and Web feed: links to the article on the web feed format RSS (link here > RSS <) are not displaying on Wikipedia articles
The link displays and works normally for me in all five tested browsers. It sounds like something in your browser is messing with the link, maybe an extension for RSS feeds. PrimeHunter (talk) 20:08, 20 May 2024 (UTC)[reply]
Resolved Thanks, didn't even think that text on Wikipedia would be targeted by a content blocker. 1Blocker "Block Annoyances" setting responsible. PK-WIKI (talk) 20:21, 20 May 2024 (UTC)[reply]
Strange CSS behavior
I recently noticed that the CSS style background:transparent seems to turn the text color dark gray when combined with the class thumbinner and viewed through the beta vector night mode. Does anyone know why this happens? Andumé (talk) 20:12, 20 May 2024 (UTC)[reply]
In general however, if you define a background color, you should ALWAYS define a text color and vice versa, if you want to avoid problems with night/dark mode. —TheDJ (talk • contribs) 10:00, 21 May 2024 (UTC)[reply]
In dark mode, there is some blanket CSS for "it has a background but is relying on inherited color" which obviously doesn't work in a lot of places. Izno (talk) 17:13, 21 May 2024 (UTC)[reply]
Link classifier missing in Vector 2022
The Link Classifier which if I recall is maintained by Anomie has disappeared from my Vector (2022) skin. I use this frequently and have just now noticed it, so I is likely something very recent. I switched back to Vector (2010) just to check and it was still available there. Any suggestions about how to get this back in Vector (2022)? older ≠ wiser21:29, 20 May 2024 (UTC)[reply]
WMF has recently changed the software so that in Vector 2022 personal Javascript/CSS are loaded only from Special:MyPage/vector-2022.js and Special:MyPage/vector-2022.css. You are loading it only in Special:MyPage/vector.js. You will need to copy whatever you want from there to the vector-2022 version, or to your Common.js at Special:MyPage/common.js (which is the best place for it - scripts are/should be responsible for loading where they should; styles may vary more so they may not be as obvious to move). Remove it from vector.js if you add it to common.js. Izno (talk) 22:06, 20 May 2024 (UTC)[reply]
Not sure whether it is related but I am using one of the user scripts (do not have time now to search which one) which, in particular, highlights in pink pages proposed for deletion. The highlighting is gone today (checked on two different devices, different browsers), which gives me a HUGE headache for CFD handling. Ymblanter (talk) 08:35, 21 May 2024 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
The Nuke feature, which enables administrators to mass delete pages, will now correctly delete pages which were moved to another title. [3]
New changes have been made to the UploadWizard in Wikimedia Commons: the overall layout has been improved, by following new styling and spacing for the form and its fields; the headers and helper text for each of the fields was changed; the Caption field is now a required field, and there is an option for users to copy their caption into the media description. [4][5]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 May. It will be on non-Wikipedia wikis and some Wikipedias from 22 May. It will be on all wikis from 23 May (calendar). [6][7]
The HTML used to render all headings is being changed to improve accessibility. It will change on 22 May in some skins (Timeless, Modern, CologneBlue, Nostalgia, and Monobook). Please test gadgets on your wiki on these skins and report any related problems so that they can be resolved before this change is made in all other skins. The developers are also considering the introduction of a Gadget API for adding buttons to section titles if that would be helpful to tool creators, and would appreciate any input you have on that.
Based on a quick search, it looks like the heading change will affect almost 300 scripts, many of which have inactive maintainers. Some arbitrary highlights from the top of the list include:
A quick way to test these scripts right now, is to enable the Parsoid beta option (which already uses the new html structure) and to disable DiscussionTools, which uses a partial form of the new heading structure. —TheDJ (talk • contribs) 08:39, 22 May 2024 (UTC)[reply]
Indeed, you can already see it in Parsoid mode (but note that there are other differences – e.g. Parsoid output has <section> tags around each section, which may require a separate set of updates in some scripts).
Disabling DiscussionTools doesn't actually change anything though. The HTML structure is the same whether it's enabled or disabled, only the styles are different. Also, note that it uses a "hybrid" heading structure currently when using the default parser, as you say, but it uses the new structure when using Parsoid.
So in short, you can just use Parsoid mode to test these scripts today here on English Wikipedia, but beware that there may be extra issues. But if they work with Parsoid, they will work with the new headings too. Matma Rextalk11:25, 22 May 2024 (UTC)[reply]
The technical 13 script was blanked, so we don't have to worry about that one.
Will the fact that they're rolling this out for only some wikimedia-deployed skins at this time make the patch more complicated? If I'm reading it right, the scripts may temporarily have to support both heading styles. –Novem Linguae (talk) 09:16, 22 May 2024 (UTC)[reply]
Where is the code for an info-box? Where does it go?
I'm trying to create some info-boxes on a small hobby wiki. It had been running fine on "freewiki.in" but that domain disappeared last year. I've re-created it on a domain I control using MediaWiki v1.41.1. I've put up all the article text from .XML backups, but all the formatting is gone.
The software manual at https://www.mediawiki.org/wiki/Global_templates/Taxonomy explains how to use {{ambox}} but not the code required for it to work. It sends me to Wikipedia, to https://en.wikipedia.org/wiki/Module:Message_box.
That, finally, has 600+ lines of code.
Where does this code go? Somewhere on the wiki? Somewhere on the server in one of the .PHP files? There's gotta be a step-by-step procedure somewhere but I can't find it. And I'm not about to do my experimenting here on Wikipedia...
Answers can be here, if this is of general interest. If not, I'd be perfectly happy getting help at my talk page. SandyJax (talk) 13:05, 21 May 2024 (UTC)[reply]
If you preview code, e.g. an infobox call, then the bottom of the window shows all transcluded templates and modules at "Templates used in this preview". It can be a long list, and the list can change if the same template is called with different parameters or circumstances (e.g. the namespace it's called from). Some of the infobox styling in the English Wikipedia is in MediaWiki:Common.css which is not listed at "Templates used in this preview" since it's not transcluded but used in another way. PrimeHunter (talk) 18:30, 21 May 2024 (UTC)[reply]
It is not malfunctioning, it is doing what it is supposed to do, to notify everyone about the ongoing discussion. But I can see how this can be disruptive to the reading experience when it is being used multiple times within a short space, i.e. at Atlanta Braves#Braves Hall of Fame. – robertsky (talk) 03:45, 22 May 2024 (UTC)[reply]
I am quite happy that Wikipedia uses the IPA as a pronunciation guide. I know the IPA moderately well, so its use is convenient for me. Promoting the IPA in Wikipedia might also encourage people to learn it, which probably might not be a bad idea.
I think that the use of the IPA in Wikipedia might often or consitently make some errors. I don’t see these errors being made in Wiktionary though. The IPA there seems to be largely fine.
the approximant rhotic (also the approximant alveolar)
/ɹ/
The English language uses primarily for a rhotic the approximant alveolar which in the IPA is represented as: /ɹ/.
In Wikipedia, this rhotic seems to always get represented by /r/, which actually represents the rolled “r”, as the “r” in the Spanish word “perro”.
I’ve suspected that this error is deliberate in that maybe the people setting up the IPA transcriptions are concerned that an upside down “r” might confuse people. Although, this doesn’t make very good sense since much of the rest of the IPA will still confuse people who are not familiar with it.
These might be described as the “basic a” vowels: /ɑ/, /a/, /æ/
/a/ and /æ/ are similar and are like the “a” in “cat”.
/a/ is more open and might be more typical for Received Pronunciation or a British English. /æ/ is similar sounding but just with an articulation that is a bit more close (closed jaw) and is probably more typical for General American English or Standard Canadian English. Distinguishing between these two is not too much of a big deal, I don’t think for general pronunciation purposes.
The /ɑ/, described as a back, open, unrounded vowel, is like the “o” in the English word “top”. This vowel is more of what is considered an “a” vowel in languages such as Spanish, Italian, and other languages. This /ɑ/ though is significantly different from the /a/ and /æ/.
I’ve seen on a number of occasions in Wikipedia in which words with the /ɑ/ sound were given IPA transcriptions of /a/. I went looking for examples in Wikipedia of this today, but had difficulty finding this.
Here’s an example from Wiktionary where the /ɑ/ sound is written as /a/.
Pronunciation
(UK) IPA(key): /ˈɒn.tʊ.ɹɑːʒ/, /ˈɑ̃ː.tʊ.ɹɑːʒ/
(US) IPA(key): /ˈɑn.tə.ɹɑʒ/
I finally managed to find an example of the /ɑ/ sound being written as /a/.
I noticed in my search for words with an /ɑ/, for words that have this sound in General American English or Standard Canadian English, that same sound in Received Pronunciation often gets pronounced as /ɒ/, which is a very open “o” and pronunciation given in Wikipedia may tend to favor Received Pronunciation.
the schwa and the caret
This is an issue that probably would have to be directed towards the IPA Association or something like that, and not Wikipedia. But, I’ll mention it here anyways.
Apparently, any phonetics course, most phonetics courses, will tell you that no word in English ends with a caret. So, take the word “the” or “California”. Wiktionary will transcribe these into the IPA as :
It’s typical to see IPA transcriptions of the words “the” and “California” as ending with the schwa, /ə/.
Transcribing the final vowel in the words “the” and “California” as /ə/ to me seems wrong. Maybe my hearing sense is off. Maybe the articulation is /ə/ but to me sounds like /ʌ/ or /ɐ/.
Give it a try? The /ə/ or schwa is the vowel sound you more or less get between the “p” and “l” in “apple” in General American and probably Received Pronunciation. Or find some online IPA chart with audio pronunciation to find out how /ə/ is pronounced.
Now try sticking that sound into the word “the” or at the end of the word “California”. Maybe I’m not getting this right, but it consistently sounds wrong! Like weird!
Maybe when speaking quickly these sounds will reduce to an /ə/ sound. But even when spoken quickly, these words can often just sound like they end with a quick /ʌ/ or /ɐ/.
I used to think that “the” and “California” should be transcribed as /ðʌ/ and /ˈkalɪfɔɹnjʌ/, with the the /ʌ/ at the end of the word. This makes auditory sense to me.
More recently though, when realizing that / ʌ/ and /ɐ/ sound very similar, that for that sound, if the preceeding consonant is more forward, then maybe the more forward of /ʌ/ and /ɐ/ would actually be articulation being used, which is the /ɐ/. So, the word “the” would more likely be transcribed as:
/ðɐ/
With “California”, this might be different. The /j/ sound before the final vowel, it’s more central so would it make the final vowel sound /ɐ/ or /ʌ/? Maybe the /ʌ/ sound fills an entire linear area that connects the more middle /ɐ/ and the more back /ʌ/, in which case it could get kind of complicated or difficult to figure out where the articulation of this sound is taking place exactly.
I suspect that if the /ʌ/ sound is preceeded by a more back consonant, such as in the English word “gut”, then the /ʌ/ sound will take more of a back /ʌ/ articulation, as you get with the Wiktionary transcription of “gut”.
This is not a technical inquiry. The appropriate venue is the talk page of the IPA key for each language, though I strongly suggest you read the Handbook of the IPA and learn the difference between a phone and a phoneme and the concept of narrowness first. Nardog (talk) 06:57, 22 May 2024 (UTC)[reply]
Issue with template
Hi there. There seems to be some kind of issue with {{Population WD}}. I would like to use it to get the bare population figure. At first, {{population WD|qid=Q559227|show=value}} was not working, and I was getting the figure plus a "<span" at the end. Primefac has solved it, at least partially. But there still seem to be some issues, as can be seen here. Thanks in advance for the help, Alavense (talk) 08:19, 22 May 2024 (UTC)[reply]
My guess is that the {{first word}} is cutting off the coding to show the "edit at Wikidata" icon, but I have a) no idea why it's doing that, and b) no idea how to fix it. Primefac (talk) 08:37, 22 May 2024 (UTC)[reply]
And, yes, nbsp is not considered one of the ASCII whitespace characters by some regular expression engines, including, according to what we've seen here, Lua's %s. — jmcgnh(talk)(contribs)09:19, 22 May 2024 (UTC)[reply]
Differentiation of subheading font sizes (or more accurately, lack thereof)
I've just used subheadings for the first time, and was somewhat dismayed to see hardly any noticeable differentiation between Subheadings 2, 3, and 4. Couldn't the subheadings be differentiated more?
Yes, I think many of us got confused at first and pointed out that h3 looks more prominent than h2, but there doesn't seem to be a consensus to change the styles and eventually we got used to it. I hope it doesn't lead too many readers astray. Certes (talk) 12:04, 22 May 2024 (UTC)[reply]
How could there be any editorial disagreement about the need for a technical fix to remedy this situation, @Certes? Of course it could lead readers astray!
It's not like the discussion going on elsewhere at the Village Pump on the topic of COI guidelines, with many senior editors all over the field as to just what COI is and what should be required of editors in self-reporting it. Augnablik (talk) 12:42, 22 May 2024 (UTC)[reply]
trying to add new GeoJSON map to virgin river article - centering is getting messed up
{{mapframe|from=Virgin River (Utah).map|text=Route of the Virgin River and the North and East Forks|frame=yes|zoom=7|frame-coord|coord=37.174167,-113.326111}}
The problem is that every time I preview my proposed change the center of the map is completely off. It's like it's pulling the coordinates of the mouth from wikidata.org and using that vs using the more central coordinate that I'm using.
Assuming that that's the case idk that I necessarily want to change it. Ideally I'd like to just overwrite it for that one map. But if that's not possible I guess I could change the wikidata.org entries altho https://www.wikidata.org/wiki/Q1676970 shows multiple coordinate locations. Would just the first one need to be changed? I'm a little hesitant to save experimental changes like that. I'd rather Preview my changes before saving them but, assuming my hypothesis is correct then I'd prob need save it all the same, even if only to save just to preview TerraFrost (talk) 12:04, 22 May 2024 (UTC)[reply]
"Publish" is a little too quick on the draw
I've been editing the Houseboat article and once again when I tried to review my changes before publishing a few minutes ago, they got published — with no summary, because I wanted to be reminded of the things I'd done in my edits. This has happened a few times before as well.
And because these edits were major changes, including the addition of new information along with a supporting citation and the removal of some existing text for greater clarity, I'll probably get a finger wag from a senior editor about this. 🫤
Aha. Thanks ... but I wonder why we have to opt in about this, given that we're not supposed to send blank edit summaries? Augnablik (talk) 12:45, 22 May 2024 (UTC)[reply]
I recall there being a discussion about this somewhere - if my memory serves me correctly, the idea of not having this on by default is to avoid there being an extra layer of friction that may discourage newer good faith editors.
In any case, there is no formal obligation to provide an edit summary; rather, the edit must be explained in some manner, or be self-explanatory, something which can be achieved after the fact through talk page discussion. WindTempos(talk • contribs)12:59, 22 May 2024 (UTC)[reply]
Facepalm I looked at that screen twice and all I saw was date & time settings! Thanks! Now my account is linked with all (two) available providers. – wbm1058 (talk) 10:45, 18 May 2024 (UTC)
Done. Success. I have a development environment which seems to be operating identically with the official-release environment I just replaced. Tomorrow I move to the next step. Make minor "hello, world!" type changes in two files, and then figure out how to submit them for review. FYI, the project I'm working on, where I hope to make more substantial enhancements soon, is discussed on my talk: User talk:Wbm1058#My MediaWiki core developers thread. – wbm1058 (talk) 01:40, 21 May 2024 (UTC)
a shortcut to avoid going through the web installer... well, now I know. I was wondering how that was done. But now, water under the bridge. I'd like to keep the database I started last year, for sentimental reasons, and just upgrade. I think upgrading should be easier than installing from scratch every time.
Resolved Thanks, didn't even think that text on Wikipedia would be targeted by a content blocker. 1Blocker "Block Annoyances" setting responsible. PK-WIKI (talk) 20:21, 20 May 2024 (UTC)
The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 May. It will be on non-Wikipedia wikis and some Wikipedias from 22 May. It will be on all wikis from 23 May (calendar). [6][7]
The HTML used to render all headings is being changed to improve accessibility. It will change on 22 May in some skins (Timeless, Modern, CologneBlue, Nostalgia, and Monobook). Please test gadgets on your wiki on these skins and report any related problems so that they can be resolved before this change is made in all other skins. The developers are also considering the introduction of a Gadget API for adding buttons to section titles if that would be helpful to tool creators, and would appreciate any input you have on that.
Resolved