Project:Current issues
 Archives |
Contents
 First page |
 Previous page |
 Next page |
 Last page |
I registered on mediawiki.org an OAuth consumer for a project I am working on. When I registered it, I used a .local DNS name in the redirect URL for development purposes. Now, I want to change it to a staging server. However, when I go to my consumer's management page, which I am permitted to do, I cannot change the URL - only the source IP addresses and RSA key. What is the process for resolving this problem?
Recategorisation of MediaWiki settings categories, discussion on restyling Template:CS cat header
For the second part, it's been taking a long time for the back-and-forth of replying, so I'm just linking the discussion here:
For the main part of this post, this is the current layout of Category:MediaWiki configuration settings:
- MediaWiki configuration settings
- MediaWiki configuration settings X.XX
- MediaWiki configuration settings introduced in X.XX
- MediaWiki configuration settings deprecated in X.XX
- MediaWiki configuration settings removed in X.XX
As you can see, (1) and (2) are both duplicates, and they both have many translation pages! I think it's complicating and effort is wasted in these. But, these are just category pages. The only text content in (1) is provided in Template:CS cat header so the category pages don't need to be translated themselves, but (2) doesn't even use the template. As for the deprecated and removed categories, they seem fine so no complaints. The only reason I have found why this was done was from the Template:CS cat header template which says it was to make the naming consistent.
What would everyone say to making all (1) categories redirect to (2) pages? I have used a script to check what pages link to (1) and I have found that they link only to each other using the template, so no pages will need to be updated to remove double redirects. I could also make a script to perform the redirects.
I also have another suggestion of modifying the layout, which would involved only adding [[Category:MediaWiki NAMEHERE configuration settings]] in each page. But it may involve edit-spam so I'm not sure. Modified layout:
- MediaWiki configuration settings
- MediaWiki introduced configuration settings
- MediaWiki configuration settings introduced in X.XX
- MediaWiki deprecated configuration settings
- MediaWiki configuration settings deprecated in X.XX
- MediaWiki removed configuration settings
- MediaWiki configuration settings removed in X.XX
- MediaWiki introduced configuration settings
Using Project:Support_desk for emergency bug reporting during the Bugzilla - Phabricator migration
Cross-posting Quim's suggestion
- As part of the Bugzilla - Phabricator migration, Bugzilla is planned to be turned to read-only mode on Friday 21 November 00:30 UTC, and Phabricator will be completely down. We will discourage the submission of bugs/tasks that can wait, but we need to have channels open for emergencies. We are proposing to use the Support Desk combined with a specific IRC channel, both monitored by Andre Klapper and other usual suspects (so we would not leave you alone here). What do you think? See the related discussion at phab:T473#10278.
For other issues not so urgent, an etherpad has been created: http://etherpad.wikimedia.org/p/bugscratchpad
Recurring spammer Hughclayton
This one is a recurring spammer who needs to be blocked at some point. Low volume but still every edit was reverted due to linkspam. Cheers
A proposal to replace protection with FlaggedRevs, discarded now that FlaggedRevs has been removed from MW.org.
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.
I thing this is a very good idea.
Countless times, I have wanted to improve - most often correct - a page or a template, and I gave up, because it was locked. → The wiki gets no gain.
Countless times also, I have edited a page, or a part of the home page, with flagged revisions, and my edit went live after a few hours or days. → The wiki gets improved.
However, in the proposal by Waldir, there is one thing I don't like : the part "except Reviewers". If we place a barrier in front of content editing, why would reviewers have a passe-droit ? Admins behaving "above the law" are a chronic disease in Wikipedia communities. If there is a good reason to allow reviewers to edit directly, then there is a good reason to allow everyone to edit directly.
This is a dead horse, FlaggedRevs has been removed from MediaWiki.org.
The Wikimedia Engineering report for August is still a draft, the link to the September summary is a red link, and {{SoFixIt}} is not applicable. But WP:BRION is alive and kicking again.
You gotta be kidding, "Previous reports" in the footer has three red links. :) m:Tech/News mostly replaced BRION. WMF reports are lagging behind due to some work shifts in their maintainers, AFAICS.
Well, those links worked seven years ago, before somebody intentinally "lost" his m+w passwords. :-| The new m:Tech/News/Latest is fine, I have a link to it on my user page.
The engineering reports have traditionally been published within two weeks after the end of a month. The reports for August and September were delayed due to several reasons, but the August report has now been published, and the September report is being drafted and will be published shortly.
That said, it's true that the engineering reports are very labor-intensive, and that's why we're considering replacing them by a more consistent combination of timely updates (in the form of Tech News and status updates) and quarterly retrospectives. See also the last paragraph of this wikitech-l email.
I'd like to import several Toolserver wiki pages on this wiki, with some regex cleanup. I lean towards:
- changing titles to pseudo-namespace format as we did for API etc., Toolserver:;
- regex change of internal links (but not templates) so that they keep working;
- run AnankeBot to add a template similar to Template:MoveToMediaWiki on top;
- perhaps manually fix some active usernames to match this wiki (e.g. 'nemobis' -> 'Nemo bis').
Ideas?
Done by Tegel
The user is blocked with an expiry time of indefinite.
I'm not sure if this is the correct place to report vandalism, but 2602:306:cc2e:efb0:59f:ad58:ff56:3a40 (talk · contribs) keeps vandalizing Help:Templates.
I'm trying to translate the home MediaWiki sidebar, i. e. "Contribute". But the creation of MediaWiki:Mw-contribute/ca is blocked!?, only exists MediaWiki:Mw-contribute/ru for other language.
For interface messages you need the right "editinterface" to edit them. On mediawiki.org, only administrators have this right: Special:ListGroupRights :)
You can request user rights here (read the opener!).
I don't think this deprecated function should still be installed at MediaWiki.org. Why not move all data of Special:Code to Phabricator and remove this extension from MediaWiki.org?
Won't that create a lot of dead links?
If it can be done in a way that (a) doesn't break the web; and (b) means the content is still fully accessible then I don't have an objection, however if either of these is not possible then I strongly urge that it not be removed.
Perhaps a simpler answer would be to remove code-reviewing rights from everyone, so the pages remain but are no longer editable by anyone?
Special:Code is very pretty and useful and it shouldn't be replaced without a clear benefit. In fact, some days ago I wanted to reply to a thread and I couldn't because it was frozen: which is okay and makes sense, but a bit against WikiNow.
I also have no time to write the code. However, is it possible to move data after data from gerrit is moved?
Maybe we should remove coder and svnadmin group from Mediawiki.org. It currently does nothing about CodeReview (though coder sill have autopatrol right). Extension:CodeReview can be on hold. But I still concern that keeping CodeReview is a risk if there're bugs in extension and this probably can be used by hackers.
Phabricator will not even have comments from gerrit: http://fab.wmflabs.org/T42#46 I'd rather support importing gerrit comments into the CodeReview extension. ;-)
[RESOLVED] MediaWiki:Gadget-externalsearch
Please could someone change the URL to HTTPS or protocol-relative?
Done, thanks for the report.
Sorry, but couldn't find any but seeming mutually contradictory information on the replace string extension. Is it alive on en.Wikibooks (meaning I have a likely precedence flaw) or not is WAS my 'Need'... but I answered my own question remembering I used it successfully a couple of months ago in another template.
- I'm continuing because...
- the one reference page has two box headers which seem to contradict themselves at the very page top, and the bugzilla linked there seems to be open and unresolved--but with a mention that everything there was now incorporated into the wiki magicword system, but that and one other.
If I'm making the right mappings from my history:
- Extension:Replace Text probably has the two warring box notices right up top... as I went to Bugzilla from there.
- Wikitext parser/Core parser functions - says it should work (but someone ought to reconcile these!)
- Extension:String Functions#replace is a very unhelpful section header with an apparently included empty sub-page.
I'd take it on, but making sure of my ground in this realm of computer science geeks is like translating German to English to read how an Electrical geek like me has to use it! best regards,
Is it correct that you have not asked a question?
Well a truly discerning read, especially of the links would have detected the message that there needs be a clarification, specifically on the string extensions of the parser functions. So no, my communication was more along the lines of a statement that this was a terrible situation that stinks!
- However, it would appear here at least, programming standards apparently no longer include the ethic that No job is done until the paperwork is finished, so I'll just take me hits on my leisure time as a lesson, and further just finished donating a bit more of that scarce resource just so others don't get screwed over by that same lack of professional ethics. Please enjoy the embedded pic, which sums it up almost as good as an icon with someone holding their nose.
- Lua scripts and CSS measures don't fix misleading references for a world wide audience that depends on these pages for reliable information. Sigh.
- Further, the one thing apparently not fixed is the ability to replace spaces with underscores to reliably construct either a Wikimarkup section link, or a usable externally linkable url in templates, both of which I have need of in Wikibooks pages involving keyword-keyword pairs or keyword-phrase pairs—who'd have thought a space could turn into such a nasty enemy to productivity! // FrankB 18:53, 25 September 2014 (UTC)
- No job is done until the paperwork is finished
Being involved in the documentation of Open Source projects myself, I can only agree. However, it is an obvious truth that developers do not like writing manuals nor documenting features. Basically, if you found something to be improved, I recommend: Go ahead and just do it! Chances are people will just be fine with it (which often means you never hear a word, but that is yet another topic).
As for the space issue, if you consider this a bug, you might want to file a BUGREPORT!
Given the bugzilla length, and the related (and reading between the lines, there are several that merged) I don't know how another might help. Further, that was why I posted here. Someone with a better handle on developments the last four years (not to mention scripting mysteries) needs to evaluate this and make that kind of call.
I will be glad to document trials of several templates where I'd expected b:template:Underscores to work the task, but it's no longer 'called' and I'd have to examine my saves (and contribs) and whatnot to refigure the trials. I'd not likely saved more than once or twice, then had to revert, so there will be some small trail. Mostly I debug in preview, so... those won't be visible. I might have an offline file or two as well. I use a programmers editor to match up curly-braces et.al. and other nesting in such templates. Easy peasey and saves a lot of grief. The rare revert will show up about that date though, so we could tell a sensible tale. //
I've created a userbox, {{User ORCID}} for users who have an ORCID identifier. You can see it in use on my user page. ORCID identifiers disambiguate contributors with similar names, and unify the works of people who have published under different names. Anyone may sign up for one, free, and I encourage you to do so, and to display it using this template. More information on the use of ORCID identifiers by Wikimedia project editors may be found at w:en:WP:ORCID.
When I tried to create a new userpage, I got this peculiar problem: File:Bobrayner pagecreation problem.jpg
- MediaWiki is trying to warn me that I'm creating a new page, but this notice can seemingly only be triggered by users who willingly click on the "Create" link or similar (not just by navigating to a currently-redlinked page), so why is a warning necessary?
- The notice is malformed and unreadable, apparently due to being put inside a narrow frame which takes up the left half of the notice area, and the leftmost strip of the warning is devoted to a pointless image which only takes a small % of the vertical height.
- Also, on trying to search this page for any related issue, I get "
An error has occurred while searching: HTTP request timed out.". Sorry if this is a duplicate.
Any suggestions?
The first two appear to be some VisualEditor issue. The other is about the old search system which is being discountinued (see Search) but still has some leftovers: please use Special:Search instead.
The first (the warning) is triggered when you navigate to a redlink. Go to Special:RecentChanges and click on any red-linked username, and you'll get the same message at the top of the wikitext editing window.
The second is a problem with the design of the template. It was designed to be displayed on a particular shape of a screen. You'll see the same mess in the wikitext editor if you have a very narrow screen (e.g., anyone using a smartphone over Mobile web, or if you drag your browser window to be narrow). It should be possible to make the text wrap around the icon, but the person designing it (years ago) was only thinking about how it would display for desktop users using the wikitext editor (because that's pretty much all there was back then).
Someone added a topic summary, but I don't see who. Thanks though for identifying the issue and reporting it!
It's still silly to link a dead feature and newbies were getting confused, so I hid the search box: [1]. Surely there is some configuration setting or hook to do it properly?
Best configuration remedy for this would be to disable LQT.
First page |
Previous page |
Next page |
Last page |
