Project:Forum

Wiki not loads doc-files saved in MS Word 2007 format 97-2003
Version MediaWiki 1.14.0 and 1.15.1. writes: file is corrupt or the wrong extension.Can you tell why this happens and what is the solution? --194.85.96.104 07:11, 19 January 2010 (UTC)

Extension help
Where should we put help content that relates to extensions? In the Help: namespace, or perhaps in another custom namespace "Extension help:"?? Happy ‑ melon 17:41, 22 December 2008 (UTC)


 * Manual: is fine. —Emufarmers(T 00:33, 23 December 2008 (UTC)
 * That doesn't strike me as very sensible: extension help content should still be licensed to PD, which won't be the case in Manual: namespace. Manual: isn't even where technical data on extensions is kept, that's Extension:... I can't think of any reason to put content like meta:Help:ParserFunctions at Manual:ParserFunctions or somesuch. Happy ‑ melon 15:29, 23 December 2008 (UTC)
 * How about subpages in the "Extension:" namespace? (e.g. Extension:ParserFunction/Installation) – rotemliss – Talk 19:41, 23 December 2008 (UTC)


 * It helps when you explain what "help content that relates to extensions" actually means. :) (Manual: holds documentation on developing extensions.)
 * Documenting lengthy usage instructions using subpages is common practice; is there a compelling reason why we would want to do it another way in this case? ParserFunctions is installed on lots and lots of wikis, to the point where it might seem like core help material, but it's still an extension.  We could document the functions from the extension in Help:Variables and mark them as "functions that may not be available depending on the wiki setup," but I think we're aiming to keep the PD help pages describing an out-of-the-box setup, to the extent that we can. —Emufarmers(T 08:06, 24 December 2008 (UTC)


 * Indeed, which is why I was hesitant to just recreate Help:ParserFunctions. The issue is, as ever, the license; wouldn't we want the extension help pages like meta:Help:ParserFunctions, en:Help:EasyTimeline syntax to be PD so they can be distributed more easily? I'm concerned that if we drop content like this into the Extension: namespace then A) it is likely to get muddled with the 'developer-level' information and be hard to find, B) be difficult to locate and extract from the set of pages in that namespace, and C) be hard to cleanly and easily port of this site. Not everyone will want to link their help documentation here. So my thoughts are that this kind of help content (that is aimed at editors of www.randomwiki.org) needs to be both PD and contained in its own little set such that admins there can come over here, export the whole of our 'standard help', plus the help pages for whichever extensions they've got installed. My immediate reaction is that it would be quickest and cleanest to create another PD namespace, say "Extension help:" so we could have Extension help:ParserFunctions, Extension help:ImageMap, Extension help:Cite, etc.  Another possible solution, either an interim measure or a permanent decision, would be what I've done by creating Help:Extension:ParserFunctions.  Upsides, no need for another namespace, downside slightly confusing page name.  As I say, however, my overriding impression is that this content needs to be public domain. Happy ‑ melon 12:20, 24 December 2008 (UTC)


 * The help namespace is aimed at being a set of basic help pages that can be installed easily on a new wiki, aimed at wiki users (no administrator info). ParserFunctions (unless I'm unaware of a change) does not ship with vanilla MediaWiki, therefore they should not be documented in the help namespace.  Extension namespace is correct for this kind of information.  --HappyDog 01:29, 12 March 2009 (UTC)
 * If the problem is whether the pages are PD or not, we can always create a template and abuse categories to track PD extension help pages. Titoxd (?!?) 03:31, 7 July 2009 (UTC)
 * But the legally-binding message is what appears underneath the edit screen. We can't change that based on categories or templates.  Happy ‑ melon 12:32, 7 July 2009 (UTC)
 * The advantage of Help:Extension: is that it looks clear that it is a user help page about using an extension; and not an extension page neither a manual page. almaghi 15:41, 12 July 2009 (UTC)

Deferred
Hi. I would like to know the purpose of marking commits as "deferred". From what I see, the changes are still in SVN. What is the result of making then "deferred"? Thanks, Malafaya 16:22, 10 February 2009 (UTC)
 * I think it just means "not reviewed yet because we don't really care, since the code isn't running on Wikimedia servers". —Simetrical (talk • contribs) 11:58, 11 February 2009 (UTC)

Sidebar localization
Could sidebar link URLs be included in $wgForceUIMsgAsContentMsg in the configuration of mediawiki.org? Especially mw-download-url would be a good idea. Main page would be fine, too, but would probably need to be changed to some mainpage-url or something, so that languages without a localized MediaWiki.org homepage would work correctly. Also “Download from SVN” should be localizable. --Mormegil 12:57, 1 April 2009 (UTC)

Not a help page
Currently the "this is not a help page" message is being largely ignored. Should we be more consistent in directing questions over to the Support desk and not handling them here? Happy ‑ melon 10:52, 14 May 2009 (UTC)
 * Sure. I see I'm the one who is curently doing most of the ignoring... I didn't pay enough attention, my bad... Sorry. MiCkE 12:05, 14 May 2009 (UTC)
 * That's ok, don't worry. It's a positive feedback loop, the more answered questions there are on this page, the more likely people are to assume that the "this is not a help desk" notice is just a mistake.  Happy ‑ melon 12:44, 14 May 2009 (UTC)


 * And besides, if you go MainPage>CommunityPortal... it does say this is the place to ask questions... "Project:Forum For questions and comments about the site." wahaha! 86.46.96.111 13:10, 17 October 2009 (UTC)

The extension DynamicPageList
The Extension:DynamicPageList has been moved to another name, Extension:DynamicPageList (third-party), and Extension:Intersection has replaced the previous entry. This creates troubles as a lot of pages refers to functionality that is not part of the extension. I would prefer that the old names would be used, even if they don't seems to be completely logical in some sense or another. Thanks. Jeblad 04:13, 31 May 2009 (UTC)
 * This was done by Brion Vibber, our CTO, as a response to 18945. We need to update links to the pages to point to their new targets as far as possible. Happy ‑ melon 09:54, 31 May 2009 (UTC)
 * Who made the move is completely irrelevant, it is a community around Mediawiki and its extensions and this creates havoc. Jeblad 16:07, 13 June 2009 (UTC)
 * Per Project:Requests, this site is not an egalitarian community like other wikis in the WMF cluster. The hierarchy of developers (patch contributors, junior devs with commit access, senior devs, sysadmins, and ultimately Brion) spills over here.  As such, the fact that Brion made the move is not irrelevant. Happy ‑ melon 18:06, 13 June 2009 (UTC)
 * Nevertheless, I feel his decision was incorrect. I don't care about what Wikimedia uses - or at least, it is only important enough to be a footer, not the determinant in title ownership. To me, DynamicPageList is the one that has more features and is actively developed, which is the "third party" extension. The Wikimedia links he mentioned seem to all link to Extension:Intersection, at least on the version pages. I have moved the Wikimedia extension to Extension:DynamicPageList (Wikimedia) and turned Extension:DynamicPageList into a disambiguation page. GreenReaper 18:17, 22 August 2009 (UTC)
 * I feel this is the best solution. By now there's a lot of copies of both extensions sitting around, and who knows what might be linking where. The fact that they're named so similar is unfortunate and has caused a lot of confusion over time. Keeping the main Extension:DynamicPageList as a disambiguation page helps reduce the confusion IMHO. ^demon 20:29, 22 August 2009 (UTC)

Main page: addition of a link to corporate use

 * See discussion.

Using MediaWiki software
THERE IS A WEBSITE MADE BY NAZIS WHO ARE USING MEDIAWIKI. NAME IS WWW.METAPEDIA.ORG AND IT IS MADE IN SPANISH LANGUAGE. IS IT LEGAL? MAY BE USED MEDIAWIKI FOR ILLEGAL WEBWSITES? --190.190.160.117 21:57, 11 July 2009 (UTC)
 * Please read the Project:General disclaimer and the GPL licence. I don't believe uses of the software is concerning MediaWiki.org, once those disclaimer and licence are token into account. almaghi 22:15, 11 July 2009 (UTC)
 * Our license does not restrict use of the software in any way; any contravention of laws in one's individual use is a matter for local law enforcement authorities or civil courts. --brion 20:27, 15 July 2009 (UTC)

Removed ED link
Removed the ED download link from the extension toolbox again, lessen the number of confused users coming into #mediawiki asking why it wont work. OverlordQ 06:01, 25 July 2009 (UTC)

how to get the URL of current page?
Hi, I'm using a social bookmark extension which shows a bookmark button on each page, including history and edit. I want them to show in a page whose URL is without "action=" (like &action=edit, &action=history), so i add this:



However, it doesn't work....at least on xampp that I try modifying the skin.

Do you know which variable contains the URL? And are these lines made correctly? Thanks a lot. --Zozzen 03:20, 28 July 2009 (UTC)

References don't work
and -tags stopped working in Finnish Uncyclopedia-project Hikipedia. The admins suspect that MediaWiki has updated the system without announcing about it. How can we make the tags work again? Irvikissa 16:09, 23 August 2009 (UTC)


 * You're running the ~1.10 version of Cite.php; upgrade it. —Emufarmers(T 21:22, 23 August 2009 (UTC)


 * Why? It worked fine until today. Something has ruined our search function also. What the hell is happening? --Pullamosso 21:36, 23 August 2009 (UTC)


 * You're running MediaWiki 1.16 alpha (which indicates that you or your sysadmin upgraded recently): you probably want to run the stable version instead. You also have a large number of extensions, and you don't appear to have ever updated or pruned them; that's another potential source of problems. —Emufarmers(T 22:08, 23 August 2009 (UTC)


 * Our best MW expert has been wikically dead for over a year now so that may be true. Anyway, thanks! --Pullamosso 22:17, 23 August 2009 (UTC)

Protect all templates
How do i protect all templates from being edited by anyone except Sysop (or maybe administrators) 59.167.194.210 03:47, 26 August 2009 (UTC)
 * See Manual:$wgNamespaceProtection (but please ask such questions on the Project:Support desk). i Alex  06:20, 26 August 2009 (UTC)

Mediawiki shows database name on each page in javascript
Hi,

I have found that Mediawiki pass the potential information like database name through javascript on each page.

/*<![CDATA[*/

		var wgDBname = "mediawikiwiki";

var wgSearchNamespaces = [0, 12, 100, 102];

var wgMWSuggestMessages = ["with suggestions", "no suggestions"];

var wgRestrictionEdit = ["sysop"];

var wgRestrictionMove = ["sysop"];

/*]]>*/

Can someone tell me how to hide this information.

Extension matrix
This seems to be broken, in that I'm seeing wikimarkup instead of the table. Viewing the latest diff caused strange things to happen in my browser. 81.110.104.91 18:37, 18 September 2009 (UTC)
 * You should ask this at Project:Support Desk; this page is only for discussion of the MediaWiki.org website. --Brian 08:55, 20 September 2009 (UTC)
 * Extension matrix is a page on this site, hence me putting it here. Seems to be fixed for now.  81.110.104.91 11:57, 20 September 2009 (UTC)

Help page for images
The help page for images Help:Images is suffering from the lack of a sample image that was deleted at some point. Maybe someone could see to it that a new sample image is added or the links are changed? Thanks.


 * I poked the page (marked it 'sighted' in FlaggedRevs), it looks happier now. --brion 17:38, 29 September 2009 (UTC)

@SysOp / Administator :: Please someone confirm my account
I cant translate any templates, please someone confirm my account. Thanks! --Ollii 15:45, 1 October 2009 (UTC)

Template:Languages/Title evolution - two alternatives
Translations in Template:Languages/Title used as title for all of the multi-language panes, maked over Languages. Currently i manually gathering translations from http://translatewiki.net/w/i.php?title=Special:Translations/loginlanguagelabel&namespace=8

In my opinion, needed separate MediaWiki:loginlanguagelabel to two messages: After this operation, Template:Languages can be migrate to using new variable.
 * "loginlanguage" as a pure translating of "Language" word
 * "loginlanguagelabel" as "loginlanguage" + ":" + "$1"

Or, alternatively, migrate to using MediaWiki-supported multi-language variable (currently used on Meta-wiki). Try use LanguagesTest as example using of a for this task.

Any of these alternatives is further good as the language of the title corresponds to the user interface language, but is not language of viewed section.

What will be the idea? Maybe this topic should be moved to Project:Current issues ? --Kaganer 16:59, 9 October 2009 (UTC)

Future development along Wikia lines...
Hi, I assume the new format on Wikia is the type of thing you guys would plan for Wikipedia. I just want to suggest that key-binds are much more comfortable for typing tasks than point and clikc. I don't know if you guys are making the Wikia changes so it is very buggy but even if it wasn't, point and click operations are nice for pictures and maybe templates but stuff like headers, bullet lists, it is much easier to edit directly on the keyboard than to lift your hands up off it and fiddle about. Your buttons here for etc are good for long stuff but the shorter stuff only gets complicated like links and headers. I don't even know if this is the place people contact developers... 86.46.96.111 23:34, 16 October 2009 (UTC)

Quick Question about releases
I do not want to dowmload and upload other files than for the english releases of media wiki. Will there be an english only releases/updates in the futere? --purple.phoenix@hotmail.com 00:32, 19 October 2009 (UTC)
 * Maybe eventually. Don't count on it happening any time soon. —Emufarmers(T 02:59, 19 October 2009 (UTC)
 * I really hate all the useless files that I need to upload and download that why I was asking. *hopes that mediawiki will have more advanced download options in the future.* purple.phoenix@hotmail.com 21:17, 19 October 2009 (UTC)

Bugzilla email address
Presumably the address given at https://bugzilla.wikimedia.org/createaccount.cgi needs to be changed, as Brion has left Wikimedia? OrangeDog 00:40, 22 October 2009 (UTC)
 * Filed a bug and Brion changed this. If you come across any other things like this, reopen bug 21237 with information. ^demon

Articles Infos
Hello. Does anyone know where to find this "Article infos" extension (see: http://www.wikigender.org/index.php/SIGI ). Thanks.Thomas --189.104.91.12 16:54, 24 October 2009 (UTC)

I am an usual user of your projects/services and it would be great if you could create a gadget for windows sidebar of MediaWiki which contains all your projects in just one gadget. I bet not only me but lots of people will download this gadget as I have seen many gadgets about wikipeda on the gadget list and they show that a large amount of people want to have it on their computers.

Looking forward to see this gadget available at the windows sidebar gadget list soon

Kind Regards Juan Lara

Is there any way to age restrict content?
Including not allowing any "Adult" tagged images to generate thumbnails unless a user is the appropriate age to view such images (Or, if it does generate a thumbnail have it be a generic image like "ADULTS ONLY"). And having "Adult" tagged articles and images be filtered based on the age of a registered user. And if it's an unregistered user having them input their age in order to visit some articles, and/or view some images. Smile Lee 11:12, 6 December 2009 (UTC)

Russian MediaWiki.org
I propose to create a Russian language section of the site MediaWiki.Org.

It will be more convenient for Russian translators and editors. Original request on Meta:

I propose to create different local site of MediaWiki at http://ru.mediawiki.org/, making both in the language edition of Wikipedia for more convenient work on the site (the current system requires the use of English names with postfix /ru in the categories). --Grigol 20:15, 2 January 2010 (UTC)

Dorkin Maxim 21:47, 4 January 2010 (UTC)
 * note: request on metawiki was rejected Lvova 21:55, 4 January 2010 (UTC)


 * I'm against this, for four reasons: 1) MediaWiki.org is about the MediaWiki software, and all development on said software happens in English. This means that even in a non-English language wiki, there will be English page names (variable or script manual pages, for example). 2) The current language system works just fine. It takes roughly the same amount of work to add /ru to the end of an existing page as it does creating an entirely new page name. If you desire a page name in Russian for easier searching, you can create a redirect to the /ru page. 3) If we were to allow a Russian MediaWiki.org, then we would then have to allow a MediaWiki.org for each other language that requests it, which would very quickly become burdensome on the developers who speak those languages in order to maintain all of those wikis. 4) MediaWiki is being rapidly developed and this separation will make it difficult to ensure that the content for all languages reflects what is currently available. As of right now, translators can add the English version to their watchlist and translate changes accordingly. Having multiple wikis makes that significantly less feasible as the translator would then have to visit a different site to check for changes. -- Skiz zerz  22:15, 4 January 2010 (UTC)
 * I agree with Skizzerz. --Jack Phoenix (Contact) 22:18, 4 January 2010 (UTC)
 * (edit conflict) There was a similar request for a German version here and on my talk page. My opinion is still the same: I don't see why we would need to split this wiki; this is just a "cosmetic" change as this wiki is for MediaWiki's documentation; not for encyclopedic content or whatever else. Creating multiple wikis would make maintenance tasks much more difficult (Languages automatically links to localised version, etc.) and would mean that admins need to check each wiki for maintenance tasks and requests rather than only this one. i Alex  22:20, 4 January 2010 (UTC)
 * I agree with Skizzerz and IAlex. Similar reasons are on the meta. --Kaganer 15:43, 5 January 2010 (UTC)
 * Strong oppose - MediaWiki is multilingual; it is not like wikipedia. And also per Skizzerz. Snake311 04:18, 9 January 2010 (UTC)
 * I see no advantages in further partitioning of WMF wikis, at least unless some hostility at existing wikis towards some group of users (e.g. Russian-speaking) was proven. English titles represent less significant discomfort to me than the need to check yet another watchlist, e.g. here. But there is yet another point. A global, widely populated community could generate more different approaches, all proposals will have more review and critic, and community will be less biased. Every non-global, split off wiki (no matter by language or by what characteristic else) will have less structure, less active users (even XX-speaking or belonging to somewhat else target audience), less review, which will result in poorer content. Incnis Mrsi 12:45, 12 January 2010 (UTC)

broken links to dynamic pages
Users can be accused of doing it wrong numerous times. Links are often provided to point this out. Only serious conflicts end up on administrative pages. Over time those links stop working leaving a bunch of dead links along with either false or just accusations. The wiki software barely allows experienced users to even find the conflicts that are serious enough to be debated.

This flaw specially on highly populated wiki's like wikipedia allows users to seriously game the system. A lot of new users already find their talk page being templated quite offensive. If the links pointing to the debate are unavailable a honest person can only assume the accusations are just.

The page history and user contribution pages lack modern UI features. It is for example impossible to see that a user has been working at a specific article for years. This gives way to much credibility to editor ranks. A moderator who only looked at the article one time is not better informed about the topic while the interface does give this impression.

As many editors edit within a narrow scope of expertise such impression is always flawed. Likewise, an administrator might want to see who was contributing to an article and who have been deleting things from it.

For example/reference: On wikipedia I've seen people create articles and trying to work at them while others kept deleting perfectly sourced material from it and eventually deleting the entire article. It makes me wonder about the different standards for making the archive of deleted pages invisible and the censorship of the biography of living person. Why would the deletion debate even be preserved if the content it debates is not available? Perhaps (after deletion) the article archive should be merged into the deletion debate to make sure everyone looking over the topic is familiar with the validity of the arguments and to allow new editors to avoid re-creating an even worse version of the article.

This seems unrelated but it is just to explain how the current software allows edit warriors to elegantly cover their tracks while hard working contributors have nothing to show for their effort. Which was not the point I believe. To not have the links to dynamic pages in addition to this really renders a contributor without any defense. It would be nice if www.wiki.com/articlename#foobar in case this article section doesn't exist would trigger an archive search and redirect to the specific #foobar section on the correct archive page. This would add serious transparency to the process.

For clarification, I can easily write my own tools for this, new users are not helped by those.

Thanks for your time and good luck,

84.104.135.141 18:33, 9 February 2010 (UTC)

Box for Extensions with no development/maintenance
I think it could be useful to have a box to mark extensions which are not developed activly or witch are not maintained anymore. This may help to solve problmes, for example that someone does not use this extensions because they might get incompatible in future. --DaSch 22:06, 16 February 2010 (UTC)

Security of MediaWiki 1.15.1
So is there any fixes for the 1.15.1 or do I need downgrade to 1.15.0? --CheerYo

Insecure extensions
I propose to delete pages on extensions that had been marked with Security alert for some time (say, 6 months) and haven't been fixed. This, of course, excludes extensions specifically intended for non-public environments. Max Semenik 08:35, 25 February 2010 (UTC)
 * Sounds like a good idea. Happy ‑ melon 09:30, 25 February 2010 (UTC)
 * Why not keep the pages and leave it up to wiki owners to decide whether the extension is worth the security risk? Even if it would be inadvisable to use some extensions as is, they might be improved later, or the code cannibalized for use in other extensions. So it's better to keep those pages around, in case someone needs them. Tisane 10:53, 25 February 2010 (UTC)
 * I think the pages should not be deleted. The Security Alert is enough, the pages can be left on the wiki like Tisane said, for any further use. Administrators should know which extensions he could use in which enviorment and decide himself. And maybe someone will even find a solution and fix it. --DaSch