However this page does not exist. This causes the client generator (a tool that generate source code from a rest api description) that im using to break. I could probably workaround, but to me the most constructive solution would be to create the data-parsoid spec page.
However i cannot, since my account is new. Does anyone agree or disagree?
Create it with what content? I believe it's upto the API owners to decide when they want to create it. You should probably continue using your workaround.
Note that Specs/data-parsoid/0.0.2 exists; you should probably file a Phabricator task about these references to unwritten(?) documentation, rather than on-wiki.
Translatable pages allow contents such as project documentation on Mediawiki.org to be multilingual. Currently a flat list with all languages in which the content is available is listed above the page contents. As the content is translated into more languages, this makes it hard for users to find the content in their language (they have to scan a long list or rely on the browser search), clutters the page, and pushes the content down.
Language list on top of multilingual page on MediaWiki.orgWikipedia page connected to other language versions
To address this issue, the Language and Product Localization team is implementing a change to use the Language selector from ULS for language selection on Vector 2022. This aims to ensure consistency with the way languages are selected on other projects, such as Wikipedia.
Specifically, the configuration option ($wgPageTranslationLanguageList = 'sidebar-only';) that we are planning to use would display languages as interlanguage links only and ignore the tag even if present on the page. You can see this in action on translatewiki.net:
We’re planning to enable this on Test Wikipedia first, and then roll-out on all wikis where Translate extension is enabled based on community feedback. Feel free to leave your feedback here, or on the Phabricator task.
FAQ
Q: Why are we making this change?
A: Currently a flat list of all languages to which the page is translated is displayed at the top of page contents. As the content is translated into more languages, this makes it hard for users to find the content in their language (they have to scan a long list or rely on the browser search), clutters the page, and pushes the content down.
Using the Language selector from ULS, makes the available language list searchable and clears up the top of the page to display the actual content. It also brings uniformity to how content language selection is done across our sites.
Q: Will I still be able to see the translation progress for each language?
A: Yes, translation statistics for each language will be displayed within circles in the same manner that it is displayed currently. The special page Special:MessageGroupStats can also be used to view per language translation statistics.
Q: Where can I see this in action?
A: This change is already active on translatewiki.net. You can see it in action there:
Q: How will this change affect the ULS for other projects like Wikipedia? Currently, the ULS in Wikipedia shows and links to Wikipedias that have the translated version of the same article in other languages. How will this new workflow affect the Wikipedia User Interface?
A: This change will not have any impact on projects that do not use the Translate extension and as such Wikipedia and its sister sites will not be impacted.
Q: This new ULS menu design shows 20 languages before scrolling. Does it mean I have to scroll and skim through maybe 90 languages to access my language if it is the last on the list?
A: No, you won't have to scroll all the way. You can type the two or three letters of your language in the Universal Language Selector for the search to fetch your language translation.
In addition, the Universal Language Selector uses different techniques to determine which languages will be most relevant to you, and displays those at the top.
Q: What is the roll-out plan?
A: We’re planning to enable this on Test Wikipedia first, followed by MediaWiki.org and then roll-out on all wikis where the Translate extension is enabled.
This is awesome. I had to actually hide this languages list with CSS on Meta-wiki several years back because of how distracting it was to me. Good to see I no longer need to hide it for myself.
I use a private mediawiki in my company and today I had a data leak by one of my employee. He has been caught copying and pasting the pages content directly into a Word document. After this I went looking at the page UserPageViewTracker to see its activity. I discovered that this morning he just visited 187 pages which seems very supicious. I wondered if there is any way to get informed when a user has a suspicious activity. I searched for a solution but mediawiki doesn't seem to have one. I thought about using Google Analytics or Matomo to track this activity but it seems impossible to send any alert when a user visits to much pages in a short amount of time. So I'm asking if anybody has a solution for this. Should I create my own extension on Mediawiki, or should I change my wiki to a knowledge database for example, or should I code a python script checking tracking the activity, or should I use a monitoring app? Or is there an easier solution for this?
If the information in question needs to have accesses audited (e.g. it's confidential and your company needs to know who accesses what when), MediaWiki is probably not the right platform for it (though I don't know what software might be a better fit).
I am pleased to announce the following individual as regional members of the U4C, who will fulfill a term until 15 June 2026:
North America (USA and Canada)
Ajraddatz
The following seats were not filled during this special election:
Latin America and Caribbean
Central and East Europe (CEE)
Sub-Saharan Africa
South Asia
The four remaining Community-At-Large seats
Thank you again to everyone who participated in this process and much appreciation to the candidates for your leadership and dedication to the Wikimedia movement and community.
Over the next few weeks, the U4C will begin meeting and planning the 2024-25 year in supporting the implementation and review of the UCoC and Enforcement Guidelines. You can follow their work on Meta-Wiki.
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". 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 based on individual needs. This makes it easier to serve the accessibility needs for more people. For more information, check out our project page.
The menu introduces a new Standard font setting. It slightly increases the size and height of the font. It was selected by looking at the preferences of editors using the beta feature, general recommendations for accessibility (which font is quickest to read for the majority of people), as well as the suggestions and designs of more than 600 Wikimedians. You will find more information on this setting below. This menu has been available on Wikipedias since June 2024.
We are now ready to make the new Appearance menu available for logged-out and logged-in users on all wikis, including this one. 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 in the week of September 9.
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.
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.
Dark mode (coming soon!): 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. Dark mode is already available in the menu as a beta feature - check it out by opting into the “Accessibility fo Reading”
This menu has been tested as a beta feature by logged-in users across wikis as well as in user testing with readers. The menu has also been the default on all Wikipedias since June 2024. Based on the findings of these tests, we changed the menu to improve the user experience, menu discoverability and ease of use, and to accommodate gadget compatibility across wikis.
The menu will appear to the right of the page, immediately under the Tools menu. Similar to the Tools menu, the menu will appear as open by default, but can be pinned. Once pinned, the menu 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. We also highlighted that information density is important to the Wikipedia experience, making the goal of the typography changes to increase font size without sacrificing information density. This was done by altering not only font size, but also line height and paragraph spacing.
Designs submitted by more than 630 Wikimedians from across 13 wikis of different languages, scripts, and sizes. The majority (~450) of test users opted for a font size that was larger than the default, with the most popular cluster being 15-20 pixels. "Standard" represents the average of the most popular cluster of community 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:
As a new admin to my wiki site, I am failing to figure out how to enable a proper approval process.
I see that a few extensions are available, and Extension:FlaggedRevs seems the best suitable. However, its page has a warning advising against its usage, but does not provide an alternative choice. I also see a few others:
Extension:Approved_Revs (seems to be incompatible with some extensions, as it is stated on their page)
Extension:ContentStabilization (it produces some errors in the wgDebugLogFile, and on their pages it says that they use FlaggedRevs)
So, what MediaWiki is using on their site? I would like to install and use an appropriate extension that will be eventually in use everywhere. Could you advise?
This wiki does not use any of the aformentioned extensions. It just lets edits get published unapproved and relies on humans patrolling recent changes to revert those that shouldn't be made. You can see what extensions are installed on a given wiki at special:Version.
So, what would you recommend to use, the one which would likely be most popular in the future? Open source concept might be working fine for MediaWiki, because it is a special site, but I need some CMS.
Both flaggedrevs and approvedrevs are popular. ApprovedRevs is a bit simpler which some people like. FlaggedRevs is not really being actively developed anymore, but ocassional fixes are still made when issues pop up. Ultimately its up to you. Both are reasonable choices.
The next language community meeting is scheduled in a few weeks—on August 30th at 15:00 UTC. If you're interested in joining, you can sign up on this wiki page.
This participant-driven meeting will focus on sharing language-specific updates related to various projects, discussing technical issues related to language wikis, and working together to find possible solutions. For example, in the last meeting, topics included the Language Converter, the state of language research, updates on the Incubator conversations, and technical challenges around external links not working with special characters on Bengali sites.
Do you have any ideas for topics to share technical updates or discuss challenges? Please add agenda items to the document here and reach out to ssethi(__AT__)wikimedia.org. We look forward to your participation!
I was trying to add back a talk page section on Writ Keeper's talk page (Re: IRC) that was reverted by XXBlackburnXx but it got stopped by the global abuse filter