Project:Current issues
 Archives |
- [History↑]
Contents
 First page |
 Previous page |
 Next page |
 Last page |
The full-text grep search that gitweb used to have is now gone in gitblit: [1]. There is a "search" within each repo, but it seems to only search commit messages. Can we please have full-text search back?
I've investigated this a bit some days ago and now filed bugzilla:49674; it's not that simple, sadly. You can now use the Wikimedia technical search for simple searches, though.
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.
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.
We've been using the translate extension for a while now on this wiki, which definitely needs more multilingual support, so I think we should greatly expand its usage, by deciding where to start. The aim is to reach more MediaWiki users (rather than developers); benefits have to be balanced by costs, and in some areas the extension is easier to use than in others (or even easier than continuing with {{Languages}} and so on). Some ideas:
- Most viewed pages: I've done some, but they often need an update/revamp in English too.
- Configuration variables: hundreds of them have the corresponding Manual: page translated and can be assumed of interest. The pages use a common pattern and most important info is in the template, so – in principle – translations can be moved to the new system (semi)automatically.
- Help pages would be the most useful in theory, but those we have here are very specific and limited. It makes no sense to translate most of them, because the "real help pages" and their translations are in fact on Meta or scattered among Wikipedias (or other Wikimedia projects.
About #3: What about the users of non-WMF wikis? Wouldn't translated help pages be helpful for them?
Yes but one should first move the up-to-date and complete English pages here from Meta and other wikis (finding a solution for licensing problems and also convincing them not to keep outdated copies around), which is not going to happen.
You may be right. I think it was a mistake to insist on public domain Help pages, and that we are reaping the harmful consequences of that decision. But to fix it would require acknowledging that a mistake was made, and sometimes people are resistant to that.
I disagree - PD help pages are a very good idea. However, it is a mistake to think they will be of any real use until we provide a workable method of distibuting them. I think it is a fairly safe assumption that if there was an easy way to import the default help pages into your local wiki, in the appropriate language(s), then that would be sufficient encouragement for the current pages to be tidied up (if, indeed, that is necessary - I haven't looked at them for a while) and, more importantly, widely translated.
I don't think think the solution here is to import existing non-English help content from elsewhere, or to try and encourage a translation drive for the help content, without having an export process in place.
Configuration settings summaries have over 23 thousands translations for the Configure extension; it would be nice to find a way to use them on wiki. I've opened bugzilla:43380 to see what's technically feasible.
I'm not familiar with the Translate extension, although I'm looking for an excuse to finally give it a try. :) Is it possible to promote a set of pages where translation is prioritized? Using a category, for instance.
Trying to translate the whole mediawiki.org is pointless and actually counterproductive, but there is a bunch of pages that would really welcome more translations, and a formal request to be translated. It would be useful for the project and for translator to identify those, and if possible get those nice stats telling that Japanese is 100% up to date, Italian is 83%, Arabic is 12% and so on.
There are two types of translatable pages based on motivation:
- Promotion: local languages are good to reach out to new users and contributors. Homepage, the hubs, How to contribute, the local Groups (mainly in their respective native languages)...
- Support: essential pages for users of MediaWiki and our technical infrastructure. The most basic and required pages of the manual, how bugzilla works how to get developer access...
Maybe it's worth having both translatable categories separate? Maybe some languages make total sense for Promotion but less so for Support (no specific examples, although I can imagine Indic or Latin languages speakers needing those translations more for Promotion than Support, since the average sysadmin / developer of those languages is used to deal with English documentation).
It is clear that the deeper you get into both categories the clearer is the need to manage some English, at least in our current reality. We could probably define a VERY LIMITED set of pages translatable here and now in both categories and then consider the addition of new pages based on actual need.
And I agree with Nemo that those pages need a review in the canonical English version before making big calls for translation. But maybe this is a feature? It forces us to go through identified pages, mark them as translatable progressively and giving more time to translators to deal with new content. For instance, we could start focusing in How to contribute and Help:Formatting, and do a first test with these pages.
Yes, it's possible to "categorize" requests for translations, see for instance m:Special:AggregateGroups. It's also possible to define priority languages and even to disable translations in some languages, but this makes little sense on this wiki. In general, people will always translate what they're interested in, not what you'd most like to have translated, therefore if something would use translations it should be translatable, while for focused translation recruitement you can have a specific priority group of translatable pages.
In short, I don't like that "very limited" in all caps, unless you consider (like me) that e.g. 600 configuration settings pages (out of ten thousands content pages) would be a "very limited" set of translatable pages. ;-) Specific pages ready for translation should made translatable immediately: I'll comment on those two on talk.
Ok, got your point. I just find useful to have a set of pages identified for volunteer translators without own itch or agenda. "I want to start translating MediaWiki content to Catalan: where should I start? Thank you."
I've created a high priority group now.
http://stats.grok.se/www.w/top was updated; the Help: and Manual: pages in the top-1000 list should probably be made translatable. Who's willing to help me?
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.
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.
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.
First page |
Previous page |
Next page |
Last page |
