Project:Current issues
 Archives |
- [History↑]
Contents
 First page |
 Previous page |
 Next page |
 Last page |
There are two extensions waiting for Git for quite some time now. It would be nice if somebody worked on it. Thank you and cheers
"This page is no longer being maintained, please request new repositories in the usual place. If wanting to import something from SVN, just leave a note in the comments."
If people were still waiting and cared, I'm sure they would go check the page and notice the message. Perhaps someone can let the users know on their talk pages that they should be re-filed at the new page.
The pages of about 50 extension which were tagged with security issues were just deleted. I think this is quite a drastic step since extensions providing according features must now we completely rewritten from the start rather than being fixed. Also deleting is the "wiki way of last resort" which is not justified in this circumstance. I think archiving extensions is preferable. Thoughts? PS I am not opposing to move these extensions out of business.
There was 37 deleted and tagged today, which now makes 58 removed in total.
This has been discussed previously (mostly on IRC) and we choose this option because we really don't want insecure extensions being used, and un-deletion is cheap (where as archiving them allows people still to get at the code in most cases). The lists of the current batches was posted to multiple IRC channels before hand as well.
"according features must now we completely rewritten from the start rather than being fixed"
These were all tagged for over 12 months. If someone cared about them, they could have fixed extensions or If this actually motives them anyone with rights can easily undo the deletion.
Here is the list of the pages deleted from this batch: User:Peachey88/Sandbox/SecExt, Did you know the oldest one was from March 2007?
The first batch of deletions appears to have been "03 April 2012" so it should be a few days before that.
Undeletion is cheap if people are aware of deletion and its reason. :) It would be nice to leave a redirect or a link in the deletion logs to a discussion or summary so that people know about it. Next time, it might just be a note in a deletion requests page or whatever.
If it is meant to keep a template from being printed, it doesn't appear to work.
Is there any coordination of people reviewing pending changes here on MediaWiki.org. I made a few changes which are still pending. Seems to be taking quite a while. But I'm not very familiar with Flagged Revisions. Maybe I just have to wait.
My changes were to Extension:NukeDPL and some related pages (see Special:Contributions/Harry_Wood) Maybe for extensions the expectation is that a maintainer of the extension would also be reviewing wiki changes? That's not going to work in this case, because it seems the extension itself isn't very well maintained
No, there is no coordination. Usually people just review stuff on their watchlist, I guess.
Where do pages for new maintenance scripts go?
I just wrote Manual:SKcreateandPromote.php. Is this in the right namespace? Is it supposed to go where it is?
It would be better to use your commit access to submit patches to the original createAndPromote.php script.
Oversight and sysadmin aren't defined by core. Instead we should probably add some sort of --group or --groups param that'll let us add any number of arbitrary groups to the user. Either using --group=oversight --group=steward or if that's not possible something like --groups=oversight,steward or --groups="oversight steward".
I would just submit it to the regular maintenance script, were it for the fact that those user groups don't exist in the MediaWiki core settings. I would recommend a default Oversight group though, possibly a sysadmin group, but not all wikis need a group higher than bureaucrat. The only wikis I find it useful for are ones where the website owners aren't necessarily the main admins. In such cases, it's useful to have a higher group in place in the event that someone gives bureaucrat access to someone who shouldn't have had it. I might submit a change for defaultsettings.php that includes an oversight group. Because of the issue, I'll work on a script that can add a user defined user group, rather than a predefined one.
It seems that I'm not able to commit there.
If you can come up with a patch that implements this more generically (per Daniel's suggestion), I'm happy to commit it for you and provide you with authorship attribution.
I appreciate that most people here know what they are looking for but a little sorting of the main menu (meaning what appears on the LH side of the screen under the logo) might just help occasional visitors. In particular the categories are not well enough sorted to mean that is much use as a menu item and the community portal just goes to the help pages (which are listed immediately underneath and would be found by anyone actually looking for that). Also on the main page there is an explanation of what mediawiki is (thanks, I have got that) but the relationship of this website to the software is a little unclear. Been like that for a long time I know... --BozMo (talk) 16:55, 3 September 2012 (UTC)
Good points and I agree.
I have started drafting the contents of a refreshed sidebar at User:Qgil/mediawiki.org_sidebar. Feedback welcome.
I'm relatively new to mediawiki.org, but I've looked for a while and couldn't find any obvious place where to post a bunch of general suggestions I have for the software. I think that a place for general suggestions is essential. Suppose you are a random MediaWiki user or developer, and want to share an idea you had for the software, where is the obvious place to go? I was about to create a Suggestions page myself, but decided to ask first, I must be missing something.
We handle "enhancement requests" (aka suggestions) in Bugzilla. The reason is that it is easy to create a wiki page and start posting ideas but it is then less easy to track those suggestions, do something about them, discuss them and notify about the progress to people interested. And you are right: this is not evident someone landing and willing to suggest something. Maybe you could suggest an approach to solve this? :)
Today there are 4504 open enhancement requests in our Bugzilla. Maybe your suggestion has been suggested, please do a search before posting just in case.
I'm curious about your suggestions. If you file a request please add qgil... in the CC and I will receive the notifications. Thank you!
(Sorry if this isn't the right place to post this.)
Since ULS is working on this wiki, perhaps it would be helpful to get more localization stuff working? Some things that would be useful:
- Mediawiki:Mainpage should be localized for each language the main page is translated into. For example, Mediawiki:Mainpage/he should be "MediaWiki/he".
- Importing commons:Special:PrefixIndex/Mediawiki:lang/ would allow for templates like d:Template:LangSwitch to be used here, to have templates display text based on the user's language. (A simple way to do this would be to use Special:Import on a page that transcludes all of these pages and check the "Include all templates" box.)
- Following this, templates like Template:Support and Template:Irc could have translations imported from other wikis.
- The main pages of non-English languages could have the top header hidden like the English main page, by adding the appropriate CSS to MediaWiki:Gadget-site.css.
Thanks! Yes, this this the right place.
- First we should decide how to translate the main page. A possibility is Special:MyLanguage/Help:Extension:Translate/Unstructured_element_translation.
- LangSwitch is not the best option for translatable pages.
- I don't have an opinion but usually people like it, so ok.
In general, please join the discussion below at Thread:Project:Current issues/ Project:Translate extension to see how we can expand translation and multilingualism of the wiki.
Although we have several templates (and parameters in templates) to mark the status of extensions, functions, and variables (e.g., obsolete ones), we don't seem to have similar templates for releases of MW itself (i.e., something that can be slapped on a page like MediaWiki 1.18 to quickly and clearly explain that it's an old version that shouldn't be used, etc. — somewhat like {{oldupgradenotes}} except not for pages about upgrades). I'm thinking {{MW release status|ancient}}, {{MW release status|legacy}}, {{MW release status|lts}}, {{MW release status|stable}}, etc? (Whatever the proper set of terms would be...) Would such a template be worth making?
I think there is a benefit, so if you want to, go ahead and make it.
Since I'm not too familiar with the subject matter (i.e., MW as a piece of software), I was hoping someone else would want to do it...
If you can create the initial templates, then I can apply them.
I've created the template (plus documentation) but I haven't added it anywhere in case there's a problem with how I've implemented it. In particular, I wasn't sure about the "legacy" and "ancient" parameter values. AFAICT, once 1.21 is released, both 1.20 and 1.19 (LTS) will be "legacy" — right? Should I add an "lts" option to distinguish between LTS legacy releases and non-LTS legacy releases? (You can see the wording I'm currently using for all the options in the template documentation.) Also, is "ancient" okay or would you prefer "obsolete"? Once I the template is set up right I can put it on the various release-notes pages myself.
I've modified and started applying your template. But there is a problem when it comes to versions like 1.20 which have a Release_notes/## page and a MediaWiki_## page.
"obsolete" is more common, though "unsupported" may be better.
Also, you might want to consider passing a version number instead of its status so we don't need to go and update pages in the future to reflect the current status. I went ahead and created {{MW version/status}}.
Yes, Krinkle's idea is the way to go. Mark, the call to K's template really should be built into "my" template instead of being passed in the template call itself. Sorry, I haven't been able to devote any time to doing this myself. I'll be back in a few days (?) to work on it some more, assuming it hasn't become perfect in the meantime... [w]
OK, I guess this technically isn't a MediaWiki.org problem, since I'm guessing it's probably being caused by something beyond the control of local admins here, but... for some reason, now as I post this, an API request for http://mediawiki.org/w/api.php?action=query&meta=siteinfo&siprop=statistics&format=json (MediaWiki.org site statistics) is somehow being redirected to http://en.wikiquote.org/w/api.php?action=query&meta=siteinfo&siprop=statistics&format=json instead. (For comparison see Special:Statistics and q:Special:Statistics.) Interestingly, a request for http://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&siprop=statistics&format=json (with a 'www.' prefix) is not being affected and returns the correct info. Anyone know what's going on, or whom I should ask about fixing this (since obviously something has changed just in the last 24 hours to cause the problem)?
Some pages that are currently fully protected could benefit from a less rigid protection scheme using Flagged Revisions, allowing more editors to suggest edits without risking having highly visible pages contain potential gibberish. I propose changing the fully protected pages to Flagged Revision's "Require review for revisions from everyone except Reviewers" setting. That way people can suggest edits but these won't be publicly visible unless approved by a reviewer or administrator. Optionally, semi-protection can be added to prevent edits from unregistered or new accounts. What do you guys think?
The principle sounds interesting. What pages are you thinking of? Maybe it's easier to just report pages that should benefit from Flagged Revisions and change their status unless there is a good reason not to. Should we try with a just a few first?
There are 7 in ns0 (none worth unprotecting), one in Extension and none in Help or Manual. Waldir, what pages are you talking about?
I'm thinking all of them, really. It might be worth revisiting what we understand by "worth unprotecting". There is always a small detail (a typo, a minor rephrasing to make things clearer, etc.) that we will overlook — nothing's ever perfect, after all. As an example, just yesterday I noticed that the main page has a link to "How does MediaWiki work?", a redirect that can be replaced with its actual target, "Manual:What is MediaWiki?". Requiring edit requests makes the workload for such small edits triple. Besides, this wiki doesn't get much vandalism/spam (AFAIK), so it shouldn't be such a problem.
In any case, we can certainly try it with one or two pages and reassess after a month or two. Any edits will only be visible immediately if made by reviewers or admins, and should any of them screw up (which is rather unlikely to happen, as you might imagine), the right can easily be removed; at the same time, autoconfirmed users will be empowered to suggest edits (to make a git analogy, that's kind of a pull request rather than a patch, where the final repository gets the actual authorship in the version history). So what do you say about a test trive?
It's no big deal. If it's just those 7 pages (I'm excuding the main page and Visual editor/Feedback which might still be linked in edit view from somewhere) I can do it immediately.
Template:Extension/de not accepting translations
I just translated stable for Extension:ConfirmAccount/de and now it's saying that it's an unknown status.
I would like to have a category with all /status pages so that we can use Special:RelatedChanges to get a RSS feed similar to this, but for status updates.
What do you think about it?
Makes sense. You'll have to check that the JavaScript helper to add updates, LST and maybe something else don't break in some way, though.
I think there will be no problem with the script if we insert the category tag between the "Last update on" line and the first heading of the status pages.
What would be a good name for it? Category:Status pages?
Fine, unless you like Category:Project status better. (only a suggestion for a more explicit name, not willing to bike-shed) :)
Category:Project status seems better. I'will use this. :-)
PS: The changes can be seen at Special:RecentChangesLinked/Category:Project status and the associated RSS feed.
Grammatik prüfen für Extension:ConfirmAccount/de
Kann jemand dieser Artikel prüfen?
The formatting of Template:MediaWiki News seems quite awkward to me, with bullet points on the dates but not on the (indented) items following the dates. I think this should be the other way 'round. Interested parties please see my comment at Template talk:MediaWiki News#Formatting and reply there, if necessary. (I would have just used {{editprotected}} on the talk page instead of posting here, but I couldn't find such a template here on this wiki.)
Dropping here:
Nikerabbit> an idea from the xwiki presentation: make one search for docs, bugs, irc and mailing list
(from FOSDEM). Done as [1], maybe it's useful for some. Google is the only option because we don't have any mailing list search (even with Google we have to rely on a mirror).
As requested by Waldir, I've placed the list of URL on User:Nemo bis/MediaWiki search for everyone to edit. Let me know if you are interested in being added as administrator.
If people like it, it's extremely easy to integrate it in the standard MediaWiki search, see for instance w:it:Speciale:Ricerca.
What do you mean? It's a sysop action (adding some JS to MediaWiki:Common.js), so this is the place where to discuss it.
Hey folks,
E3 deployed Extension:PostEdit and Extension:GuidedTour here on mediawiki wiki today. This is partially because they are dependent on each other, and we want to allow volunteer developers bulding tours to test things out here.
If you want to see how GuidedTour works in a general sort of way, you can force a tour by adding ?tour=test to any URL here. If you've edited in the last six month on most of the top ten Wikipedias, you'll already know what PostEdit looks like. If it bugs you and you want to hide it, add the following snippet to your personal CSS:
.postedit { display: none; }
P.S. Apologies if this is the wrong spot to announce.
Have you announced this anywhere else? Is there a wiki page explaining / discussing the implementation of Guided Tour in mediawiki.org and what could we do with it in order to e.g. help new users and contributors?
There is documentation at the guided tour extension page linked above, and at guided tours. I previously announced this on the local wikis where it was added, and we've held IRC office hours about making tours.
See Category:Top level, as example. With trying clicking to [+] button near any subcategories, returned error message "categorytree-collapse-bullet: Parse error at position 0 in input: "
Is it appropriate to import w:id:Bantuan:Pywikipediabot to Manual:Pywikipediabot/id ?
First page |
Previous page |
Next page |
Last page |
