Talk:MediaWiki

This page is for discussing the MediaWiki page.

---

Assorted new feature requests

The following discussion should be moved somewhere appropriate but I don't know where that would be. Perhaps some things belong on MediaZilla? Brianjd | Why restrict HTML? | 12:32, 2005 Apr 2 (UTC)

This page, originally Talk:Wikipedia3, has been initiated for purposes of discussing new feature requests - bugs should be in another file, say wikipedia3_bugs <-- alter this link if the file is renamed.

Features and questions about features:

• ease of linkage with php-nuke and other standalone php applications based on it
  • Not sure how to go about this; articles and comments in php-nuke seem to be identified primarily by numerical id, which isn't very easy.

• support for embedded XML tag schemas within wikitext - for instance to let a bot dig out well defined name, location (latitude/longitude, street address), and time/date information.
  • Agreed - I was hoping this was already available. For instance, I'm trying to integrate google Maps with wikimedia. I've made a template that makes XML nodes and attributes, but the '<' and '>' are ouput as &lt; and &gt; repectivly.
  • Suggestions for "heavy" markup are generally pooh-poohed as un-wiki, discouraging contributors who aren't HTML-trained from participating. However, semantic markup would be useful. Some kind of compromise is needed.

• integration of watchlists and such into an XML-based schema for notification via other media e.g. email.
  • Agreed, we need more RDF and XML stuff to make life fun! Suggestions welcome. Code better. :)

• integration with the IEEE's w:foundation ontology for such tag schemes

• make visible the number of page views FOR EACH VERSION OF A PAGE, AS PART OF THE "Older Versions" PAGE. This can be recorded at the moment it's submitted, and is thereafter simply static information that is part of the page's record. The counter in the database can be reset to zero to count page views on each new version. Visits immediately followed by an edit should not be counted at all. This reduces server load from the old/misleading version-ignorant view counter.
  • That wouldn't reduce server load since the current counter still needs to be updated on each view, but it's a pretty good idea.
    • Ah, but it would reduce load if the web server's logs were just cached off to the side, and consulted only with background processor power to update the database. Worst case one could avoid doing this until the page was updated - which would mean keeping more logs around longer, but cost nothing until time came to check in the new revision. For instance a background process could be created the moment something is opened to edit, which counts up the accesses, and that information can be ready for submission with the edited new version.
      • When you update the counts is completely orthogonal to how you lump them together.
      • Side effect: this would enable better access to usage logs, which would have other positive impacts on wikipedia.
        • Such as...?
          • Discussed in that article. But if you have to ask, there's no point. Either this is an open project that shares all information about itself, or it isn't, and eventually must be replaced by another that does.
            • You say that as if there were such an article.
• A more bulletin board like talk page (of course also fully editable). On controversial/big topics the discussions get chaotic.

• Wiki software has a feature to move pages. That functionality can not be used for merging two pages with simular content. As merging two pages are probably not easy, an append functionality would be nice to have. The append functionality would append the history information as well. So the merging process would look like this: 1.) Append one page to the other. 2.) Delete the old appended page. 3.) Reorganize the content of the new page. The page structure will be lost, but the content history will be preserved. Ervinn 14:24, 13 September 2006 (UTC)

Data downloads

From http://wikipedia.sourceforge.net/:

"Data downloads See download.wikipedia.org for circa weekly backup dumps of the page databases."

Huh? I thought that was a MediaWiki site, not a Wikipedia site. Brianjd | Why restrict HTML? | 12:29, 2005 Apr 2 (UTC)

Unstable wiki software?

Why are we upgrading the Wikimedia wikis to MediaWiki 1.5 if it is still unstable? Brianjd | Why restrict HTML? | 05:24, 2005 Jun 29 (UTC)

MediWiki 1.5 is now in beta. In MediaWiki's release system, "beta" means "when we're ready to put it on Wikipedia, but third-party users should wait a while for a public release". --brion 07:06, 29 Jun 2005 (UTC)

The Wikimedia sites are public sites. It seems weird that the software can be ready for some public sites but not others. Brianjd | Why restrict HTML? | 08:00, 2005 Jun 30 (UTC)

My guess regarding that issue:

• (only) using the Software on a public site ensures that it will definitely be heavyly tested.
• if some weird bugs or problems would occur during it's use on Wikipedia-sites, developers are able to quickly react and fix them
• such a quick reaction by the software developers wouldn't be possible if problems occur on some other sites (they might not even know about), thus it'll be wise not to use the software there.

-- mIstA 01:59, 2 November 2005 (UTC)

We have a prominent "edit this page" link. Let's have a prominent "report bug" link. See feature request 3865. Brian Jason Drake 08:40, 3 November 2005 (UTC)

Spanish alt text in English interface

Just curious: is it a bug of unflushed browser cookie cache or that of MediaWiki tuning?--ACrush ^?!/_© 13:10, 18 July 2005 (UTC)

Never heard of such a problem. Can you provide a set of steps to reproduce it? --brion 08:54, 20 July 2005 (UTC)

Logo

Why aren't we using the other logo with "better lettering"? Brianjd | Why restrict HTML? | 13:58, July 22, 2005 (UTC) (signature added later)

a) We never saw it before and b) it looks pretty bad, like somebody opened it in MS Paint, drew a solid black background, then wrote in a primitive bitmap font. --brion 08:50, 20 July 2005 (UTC)

Even so, I think it is already an improvement, and can be improved further. I wonder why the original poor lettering was chosen.--Patrick 10:23, 20 July 2005 (UTC)

Latest stable version?

Is 1.5beta 3 (the version currently used by Wikimedia wikis) really "the latest stable version", as the sentence in the article says? Of course, the sentence in the article just displays the version we are using - is that correct? Brianjd | Why restrict HTML? | 14:14, July 22, 2005 (UTC)

Move mediawiki info to MediaWiki.org?

Is there a plan to move Mediawiki related pages from this meta-wiki into the wiki on mediawiki.org? At the moment we have a situation which is highly confusing. It requires some drastic reorganisation. Nobody replied to my comment here: meta.wikimedia.org_vs._mediawiki.org. Since writing that I've encountered several other examples of information which I would expect to find using a search on mediawiki.org . I'm not saying this for my benefit. I know where to go for mediawiki related information/discussion ...and it ain't mediawiki.org!

I suppose we should move pages across there, but there are a lot of pages (all the handbook and installation guides), and they are no doubt interlinked with the rest of this wiki to some extent, so that would be quite a daunting undertaking. Would it leave behind a gaping hole in this wiki. Probably. Any other options? Perhaps we could change the set-up so that MediaWiki.org actually points at the mediawiki part of this wiki (perhaps with some page context skinning tricks), or keep the wikis seperate and have some clever cross-linked search machanism? -- Harry Wood 11:21, 11 October 2005 (UTC)

According to [1] the idea is to develop a simple user manual. The help on Meta is more a reference manual. Links between corresponding pages would be nice.--Patrick 00:15, 12 October 2005 (UTC)

Ah yes ...and I see that plan. In fact I just contributed a bit to this. Seems like a good idea. And I've linked to it more prominently from the Documentation page.

But this is not 'the idea' of MediaWiki.org. On the about page it says "This site is meant to become the first access point to the world of MediaWiki, collecting and including nearly all important information about it - in the long run.", so this implies that there should be some kind of migration of information from here. I've added a small clarification on the Documentation page there, although it's still not really clear. I think, as it stands at the moment, people are just going to be confused by mediawiki.org, and they wont find what they're looking for if they try to do a search on there. -- Harry Wood 16:59, 29 November 2005 (UTC)

Oh. My link to Public Domain Help Pages was dropped from the Documentation page. I don't understand the reason for that, but I guess it confirms that people (or Bdk at least) does not see that as a significant part of what mediawiki.org is all about. -- Harry Wood 12:42, 30 November 2005 (UTC)

Please try to avoid speculating about other person's aims as far as you didn't get an answer (especially don't wrongly blame someone, as you did above, before you've asked the person, and especially don't spread such a discussion over more than one wiki). And if you expect other users to do something you want (perhaps a clever cross-linked search machanism, as you noted) you could file a bug report in addition for such a request, hm?

I don't see no reason to rush the rework of mediawiki.org, instead of planing carefully, what has to be done, clarifying who can do which part and so on ... (see also my answer).

To improve search on MediaWiki.org is a reasonable idea, of course. I'll add some slight links as they're common on other projects when I feel like it. By the way, http://www.mediawiki.org/FAQ already redirects to meta. --:Bdk: 11:22, 7 December 2005 (UTC)

Sorry Bdk. I don't mean to be blaming you for anything. I'm just trying to understand the purpose of mediawiki.org and the way it relates to this wiki. As you say, I've been speculating on the matter, and trying to answer my own questions (no harm in that is there?) but I wasn't really getting replies from people. That was the main reason I spread the discussion onto this wiki (it does also relate to this wiki after all). Anyhow you recently replied here, and this explanation is very helpful. I can see I should get on IRC some time to understand what's going on around here better. -- Harry Wood 22:46, 7 December 2005 (UTC)

Really, no problem :) and thanks for your answer, Harry. --:Bdk: 08:31, 12 December 2005 (UTC)

I agree with Harry Wood. It also seems wrong the MediaWiki.org is a wikimedia project, as far as I can tell, all versions of MediaWiki, except maybe the earliset ones, have been intended both for Wikimedia and elsewhere (which seems to the why MediaWiki is so packed with features). I personally like to think of MediaWiki serpately from Wikimedia. Also, I'd suggest that big reports at MediaZilla both Wikimedia wikis and other sites using the same software, paticularly Wikitravel, which is far as I know is the largest non-Wikimedia MediaWiki intallation and was one of the first customers for the software outside of Wikimedia. Myrt|^comments 16:56, 20 November 2006 (UTC)

"It also seems wrong the MediaWiki.org is a wikimedia project" - Whose else project should it be, at least for the time being? Of course, the exclusive funding of development by the Wikimedia Foundation leads to a systemic bias in the features of MediaWiki. It's clearly not a general-purpose Wiki. --JensMueller 19:15, 11 January 2009 (UTC)

This page needs to be refocused

Right now, it's a haphazard jumble of links that were gradually slapped on as time went on. What exactly is this page for? Is it a portal into the depths of documentation on meta? Is it a description of MediaWiki, a few links, and nothing more? Is it something I failed to see? What is it? Ambush Commander 03:26, 4 March 2006 (UTC)

IMO, it's about MediaWiki from the perspective as a foundation project. --JensMueller 19:16, 11 January 2009 (UTC)

Links to versions point to wrong versions

The links appear to point to the wrong pages - 1.9.3 points to 1.8, 1.8beta points to 1.7. I'd change it, except that since it seems to be consistently wrong maybe there's a reason I don't understand for this being the case.

I put a notice on {{latest major version of MediaWiki}} as a trial for quick comparison. Mulukhiyya 10:19, 3 May 2007 (UTC)

Math formula transparency

There has been this patch for changing the white background of formula PNGs to transparent. So my question is: Why isn’t it applied at Wikimedia projects? I think it would look far better that way. —Quilbert 13:12, 17 October 2008 (UTC)

MediaWiki development

IMO MediaWiki should become a full-fledged project, and not just a support project for the "content" projects. At the moment, the features of MediaWiki IMO are totally based on Wikimedia-centric requirements, ignoring that MediaWiki is used by a lot of other people out there. The installation process is deterring possible users, just consider sentences like "The MediaWiki system is made up of many different parts. Once you have installed each of the components, you need to configure them to work together." (on mw:Manual:Configuration) ... Achieving a coherent and flexible architecture suitable for different needs will require a lot of clean-up and development efforts. I suppose there a lot more hacks in MediaWiki than this one. I suppose there will be quite some people willing to donate money specifically for MediaWiki development, so maybe some thoughts should go into that, as well. --JensMueller 01:17, 11 January 2009 (UTC)

Download issue

While trying to retrieve the URL: http://toolserver.org/~vvv/mw-nightly/pool/extensions-nightly-r62560.tar.gz The content is blocked due to the following condition: The object is infected. No Download possible. Report: HTML/Crypted.Gen
My fault or Wiki-fault? --Kevin Heidemann 07:54, 16 February 2010 (UTC)

Image handling and external SEO, problems and feature requests

How do we persuade search engines to read the /File: image info pages?

On normal websites, thumbnail jpegs point to larger versions of the JPG, but on MediaWiki, they point to something that masquerades as a JPG (because the url ends in "jpg"), but it's actually a web page. So the risk is that Google doesn't touch the page because it's supposed to be an image file, and Google Images also doesn't touch the page (and doesn't get as far as the preview image or the final image) because as soon as it tries to access the page, it finds that it's NOT an image file after all, and bales out. Could we maybe allow the option of appending something like "-info" onto the end of the info pages? Wikipedia has now solved the issue if getting its FILE: pages indexed, but I'm damned if I know how they did it. ErkDemon (talk) 12:42, 10 September 2012 (UTC)

Preserve image metadata when generating thumbnails and smaller previews (option)

Currently I'm spending a lot of time embedding metadata into image files, because it makes the files easier to sort, it's good to have important information permanently attached to a file instead of being held on some external database, because that way the data always travels with the file (or with copies of the file), and because Google loves embedded metadata.

However, my MediaWiki installation currently seems to be stripping out all the metadata whenever it makes a preview image or thumbnail. This is BAD. Programs aren't supposed to destroy things like copyright data when you upload files. It also means that when search engines look at thumbnails or previews on a MediaWiki installation, they can't categorise those images by the embedded metadata, because it's been helpfully removed. This also makes it difficult to recommend MediaWiki to organisations in the the heritage sector, becuase those guys are very big on metadata and info preservation.

At the very least, could we have a #wgPreserveMetadata option? ErkDemon (talk) 12:56, 10 September 2012 (UTC)

Edit default ALT="" info, centrally, on the image's info page, for all occurrences of the image

We're supposed to be using ALT="" tags for a range of reasons including SEO and disability support, and MediaWiki now includes manual support for ALT="". However, it doesn't generate ALT tags for auto-generated thumbnail galleries or for lists of images by category, and there's no obvious way to fix this.

Since every image on MW has its own central info page, this page would ideally have a textbox where we could enter a default "ALT=" string for the image, this could then be used every time a thumbnail of the image appears on MW, unless someone's overridden it with their own ALT= tag on the final page. MW would score points for solving a "disability access" problem, search engines would find it easier to understand the contents of MW pages and MW gallery pages, and editors would benefit from only having to input ALT= data for an image once, at source, rather than having to track down every instance of the image being used, and edit every page, filling out the same info each time (which is a rotten and unrewarding job). ErkDemon (talk) 13:19, 10 September 2012 (UTC)

Image info "Preview" button

The info page about an image can contain links and categories and template references, just like any other MediaWiki page. These can be really useful, but because there's no "preview" button for the associated wikitext, you have to upload your file and create the associated text "blind", look at the results, and then go back and re-edit any faulty links or category data. There should be a "Preview" button when you create a "File:" page, just as there is for creating "normal" text pages. ErkDemon (talk) 13:35, 10 September 2012 (UTC)

Proposed project: Advanced XML for MediaWiki

See here.

New Editor experience

(cross posted on idea

1. We are losing new editors as 84 $ of articles fail, and we let them waste 2 to 4 hours creating them

{{quote "did you know that an average of 79 nominations per day were made between 2005 and 2020, for a total of 449,950 (and only 16% of them closed keep)" User:JPxG}}

1. There is more than a 50 % chance that a new genuine editors first edit will be reverted, and they will leave in 2 months
2. The Afd debate is often larger than the articles
3. Notability is unpredictable - even AfD don't vote 100%.
4. Our procedures have an impossible learning curve - and the cost on a non-notable article is peanuts
5. We encourage readers to brave and create an article if their search fails
6. We are measuring editors using tool they don't have access to
7. Our NPP tools do not require comments, and our training advises them not to help
8. Or false positive rate for AfD marked is 20 %, Those 29 % of articles still get to feel bad (this excludes vandal, scam,....

Needed

1. An article editor should be able to predict success
2. All editors should be able to do the same checks on an article

A simple consistent measure that is checked in the Article Wizard

• is there enough for a start article? (ask google to autocheck)
• Ask google to give us a tool estimating notability worldwide and by country
• Use the NPP tools for reference relibaility (based on fact check site)
• Refer borderline under to Project who can make decision which can then not be NPPed
• Allow projects to override notability "There are no rules"

But

1. Force a user that passes notabiity to stay in draft until start class article.
2. Use rater to automatically advise them of status and issues

Or give the user to search n0n-notable articles kept in a seperate database Wakelamp (talk) 07:41, 28 November 2021 (UTC) (talk) 14:18, 23 November 2021 (UTC)

New Editor interaction	Exp Editor Opinion	Good Article	Good Artticle AfD	Good Article AfC	Vandal	Vandal AfD
Starts an article	NA	Excitement			Joyful
Uses Wizards		Confusion
Edits		Worry
Saves - Draft Article		NA		Worry	NA
Saves - Draft Article to AfC				Uncertainty
Waits for AfC	Backlog to fix			Indifference Frustration
AfC - Disccussion	Satisfaction Frustration			Pleased Confusion Upset
AfC - Fail	Uease			Anger
AfC - Pass	Satisfaction			Relief
Publish Article	Backlog	Pride			Amusement
Screen dump of artcile	NA				Pride Status
Publishes Article accidently and NPP/Other Edits immediately	Satisfaction	Upset			Amusement
Tools - tags	Satisfaction	Frustration
NPP - AFD	Pride	NA	Shame Anger	Fear
Further Edits	NA	Ok Upset			Pride the longer it lasts	Amusement
Edit Reverts	Satifaction	Guilt Anger			Amusement	Amusement
AfD -Pass		NA	Relief	Annoyed	Amusement	Amusement
AfD - More work			Frustration	Frustration	Amusement	Amusement
AfD - Fail			Anger	Anger	Amusement	Amusement
User page for Deletion		Indifference Anger Hatred			Amusement	Amusement
User Page edited (Personal Page)		Anger Hatred			Amusement	Amusement
User Talk (personal space)		Safety Thankful Friendly Relief Confusion Rejection Frustration Anger			Troll
Talk	Satisfaction
Teachouse	Satisfaction Unease Frustration	Thankful Relief Frustration
Help Desk	Satisfaction Stress Frustratio

--Wakelamp (talk) 06:35, 28 November 2021 (UTC)

MediaWiki Version

This page says that 1.39.2 is the latest version in several places, but the latest version is 1.40.0. I am not sure what to update to make it say the correct version. Koshchki123 (talk) 02:21, 26 July 2023 (UTC)

Nevermind, I have figured it out Koshchki123 (talk) 02:23, 26 July 2023 (UTC)