Project:Current issues
 Archives |
Contents
 First page |
 Previous page |
 Next page |
 Last page |
Failed to mark Help:Magic words for translation:
Function: MessageGroupStats::clearGroup Error: 1205 Lock wait timeout exceeded; try restarting transaction (10.64.16.27)
Too many translation units?
Still happening... please file a bug, hopefully the WMF DB admin will help.
This is probably https://phabricator.wikimedia.org/T53410
Shirayuki, good news: Nikerabbit has fixed the bug (hopefully). Let's remember to test and mark the page for translation... in few minutes? or perhaps next week.
Proposed by Florian, MZMcBride, Glaisher and devunt at phabricator:T87797.
Hi,
As you try to run an upload from MediaWiki: http: //hostname/mediawiki/index.php? Title = Special% 3AUpload
We get this error and the file is not loaded:
The file you uploaded seems to be empty. This might be due to a type in the filename. Please check whether you really want to upload this file.
Doing a bit 'of research, I found the link where it would seem that they solved:
Anyone can suggested how to resolve this problem?
It seems the default search namespaces on this wiki haven't been updated for some time. Just now I searched for apidisabled in the search box, and only got 1 result, which was some release notes page. What I really wanted was API:Restricting API usage.
Currently the following namespaces are in our default search namespaces:
- (Main)
- Help
- Manual
- Extension
I propose that we add the following namespaces:
- API
- Skin
Any comments?
Good idea.
I believe you need to log a ticket in the bug tracker for this kind of change, as it requires modifying the site config files.
+1 Should be an easy change with a lot of benefits.
Yep, makes sense; let's also include them in content namespaces if we didn't yet.
Starting from yesterday morning, I cannot use the Special:Translate. When I clicked the strings, nothing happens. This only occured if I'm logged in.
Here's the error found in the browser console:
TypeError: mw.config.get(...) is null" TypeError: mw.config.get(...) is null Pelacakan susunan: util.getUrl@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T194503Z line 4 > eval:9:119 VeInitMwTarget@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=Base64.js%7Ceasy-deflate.core%2Cdeflate%7Cext.visualEditor.base%2Ccore%2Cmediawiki%2CviewPageTarget%7Cext.visualEditor.core.desktop%7Cjquery.visibleText%7Cmediawiki.api.edit%7Cmediawiki.feedback%2Ctemplate%7Coojs%2Coojs-ui%2Cpapaparse%2Crangefix%2Cunicodejs%7Coojs-ui.styles&skin=vector&version=20150107T194504Z&*:641:594 VeInitMwViewPageTarget@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=Base64.js%7Ceasy-deflate.core%2Cdeflate%7Cext.visualEditor.base%2Ccore%2Cmediawiki%2CviewPageTarget%7Cext.visualEditor.core.desktop%7Cjquery.visibleText%7Cmediawiki.api.edit%7Cmediawiki.feedback%2Ctemplate%7Coojs%2Coojs-ui%2Cpapaparse%2Crangefix%2Cunicodejs%7Coojs-ui.styles&skin=vector&version=20150107T194504Z&*:671:643 getTarget/targetPromise<@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T194503Z line 4 > eval:53:1245 .Deferred/promise.then/</</<@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T194503Z:47:126 jQuery.Callbacks/fire@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T194503Z:45:106 jQuery.Callbacks/self.fireWith@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T194503Z:46:431 .Deferred/</deferred[tuple[0]]@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T194503Z:47:765 handlePending@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T194503Z:159:424 runScript@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T194503Z:161:140 execute/</checkCssHandles@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T194503Z:161:613 execute/</cssHandle/<@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T194503Z:161:743 jQuery.Callbacks/fire@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T194503Z:45:106 jQuery.Callbacks/self.fireWith@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T194503Z:46:431 jQuery.Callbacks/self.fire@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T194503Z:46:474 addEmbeddedCSS@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T194503Z:156:502 addEmbeddedCSS/<@https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T194503Z:155:963 load.php:150
Uncaught TypeError: Cannot read property 'replace' of null load.php?debug=false&lang=id&modules=ext.centralNotice.bannerChoiceData%2CbannerController|ext.cent…:386 util.getUrlload.php?debug=false&lang=id&modules=ext.centralNotice.bannerChoiceData%2CbannerController|ext.cent…:42 TranslateEditor.prepareEditorColumnload.php?debug=false&lang=id&modules=ext.centralNotice.bannerChoiceData%2CbannerController|ext.cent…:31 TranslateEditor.renderload.php?debug=false&lang=id&modules=ext.centralNotice.bannerChoiceData%2CbannerController|ext.cent…:31 TranslateEditor.initload.php?debug=false&lang=id&modules=ext.centralNotice.bannerChoiceData%2CbannerController|ext.cent…:48 TranslateEditor.showload.php?debug=false&lang=id&modules=ext.centralNotice.bannerChoiceData%2CbannerController|ext.cent…:68 (anonymous function)load.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T1…:65 jQuery.event.dispatchload.php?debug=false&lang=id&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150107T1…:60 elemData.handle
Anyone having this problem too?
Yes, but not everyone. Thanks for reporting.
Told my password was wrong, I reset it. Got new temp PW in email. Trying to log in with that. being told my password is wrong.
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:Titleblacklist
Hi! There is a problem with one BlackList entry. This one:
- #Allows creation of pages with titles too similar to existing pages
- .*(е|а|о).*
It doesn't allow (new) users with cyrillic SUL name to login to MediaWiki site. Cause they usually contain these cyrillic (е|а|о) characters. You need to either remove this entry or improve it somehow.
@Jasper Deng: Can you take a look?
@Jasper Deng:@Florianschmidtwelzow: A week has passed. Anything? Our users still cannot enter MediaWiki site nor create their own user pages if their SUL usernames contain any of these 3 characters. The only exception is for those users with cyrillic SUL names who had registered here before this blacklist entry was enabled. Are you gonna do anything about that or should I address someone else to solve this problem?
@Piramidion: I have commented out this rule for now, so it should work, if this is the real problem. Can you test it and give a response, if it works now?
@Jasper Deng: We should check, if we need this rule and should re-enable it with some adjustment?
Thanks! I will tell the user(s) who couldn't enter MediaWiki under their own SUL login to try again. Earlier one user (now an administrator on ukwiki) had got the message that "this username is blacklisted on MediaWiki" or something like that. Now it should be fine. I will post the result here.
Yes, it works! You can check it yourself :) Thanks again!
Manual:Installation guide has one section with a 400 words summary, but then links to a "Main installation guide" composed of 4+4 more pages. None of these pages is translatable. Can we consolidate truly important information and make it translatable? Currently one is supposed to find the following logical steps.
- Download
- Download is the page
- Template:DownloadMediaWiki duplicates most info
- Download from Git is sometimes linked instead from docs
- Manual:Installing_MediaWiki#Download_MediaWiki_software duplicates it again
- Manual:Upgrading#Unpack_the_new_files again
- Requirements
- Manual:Installation requirements
- Manual:Installation guide has a largely duplicative summary (which I've now transcluded in the former). Does the complete page really offer any additional value to users (as opposed to devs)?
- Repeated in Manual:Upgrading#Check_requirements
- Actual preparation of requirements: Manual:Installing_MediaWiki#Create_a_database takes most of the space in the guide.
- The actual installation
- Manual:Config script is the page (marked outdated!)
- Manual:Upgrading#Web_browser repeats in part
- Misc troubleshooting and alternatives if something went wrong
- Manual:Chmod and [1]
- Manual:Installing_MediaWiki#Uploaded_files has some warnings and may be duplicative of Manual:Configuring file uploads
- FAQ#Installation_and_configuration
- Manual:Errors_and_Symptoms#Installation_Errors
- Category:Installation
- Configuration
- Manual:Configuring MediaWiki
or Manual:Configuration#Configuring MediaWiki (merge proposed) - A handful of pages linked from there for specific config issues like Manual:Short URL and Manual:Page customizations
- More supposedly MediaWiki-specific server setup information, like Apache configuration, robots.txt, texvc, Comparison of extensions in distributions, ...
- Manual:Performance tuning
- Manual:Extensions
- Other stuff indexed in Manual:System administration and Manual:LocalSettings.php
- Manual:Configuring MediaWiki
- Maintenance
- Manual:Upgrading: this is what most people forget to do, but the page is largely duplicative and doesn't make a compelling case for upgrading.
- Manual:Administrators should be redirected to relevant help pages.
- Manual:System administration which links 10 more manual pages not mentioned above.
- Informative material
- Manual:What is MediaWiki? (cf. the dev-oriented Principles)
- Manual:MediaWiki feature list
The pages in bold are part of the official Template:InstallationNav (which complements Template:MediaWiki Introduction): they are supposed to be the official path and need special care and coordination.
Given Chad's comment, I'm also going to tag all "platform-specific" manual pages for merge to the main ones. Common parts can be merged and transcluded on the specific pages, while really platform-specific additional information can be left there. P.s.: for a start, I removed 5 guides on obsoleted systems and marked the others for merge.
Thank you for this!
I made Manual:LocalSettings.php translatable and expanded Manual:System administration by merging Manual:Configuration.
- Manual:System administration could be useful if it becomes a reasonable index/step by step guide/tutoring of the really important pages in Category:MediaWiki for site admins (allowing to remove respective information from the general installation manual), but I'm not sure of its current role.
- Manual:LocalSettings.php is very visited, but it's quite a mess. I doubt it kept anywhere close up to date, is it currently making a good service to users?
I wonder what's the purpose of making Manual:LocalSettings.php translatable if you doubt about the usefulness of that page or if you plan/propose to improve/restructure it.
The page is vastly correct and the strings contained in it look rather stable, so it's ok to translate it. It is my impression that some consolidation will be needed for that page (reducing total amount of text around), but not a rewriting.
I've tried to make the essential stuff transcludable, and I've trimmed some more pages.[1]
IMHO the direction is rather clear:
- always defer to other sites for guides on how to set up PHP etc.;
- keep all the steps internal to MediaWiki (like installer, config script, LocalSettings.php) in their own, shared manual pages;
- in all the setup-specific pages, just transclude the former and maintain only:
- information on packages available and how to use them (debatable, should be on their sites whenever possibles),
- OS-specific instructions which can't be found anywhere else, like specific paths to put in MediaWiki config or RAM/suhosin requirements and the like.
I am making this thread on his behalf.
User:MisterLambda is blocked for being a "vandalism-only account". From what I've observed, his account has not performed any vandalism, and his contributions include an extension.
Some hours ago, FancyCaptcha was disabled on this wiki for 18 minutes. There was some more spam coming in as result, let's find out at Extension:ConfirmEdit/FancyCaptcha experiments exactly how much and what abusefilters can be set up to reliably stop it.
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.
First page |
Previous page |
Next page |
Last page |
