Project:Current issues
 Archives |
Contents
 First page |
 Previous page |
 Next page |
 Last page |
There is such a proposal, see [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org. This is the place where consensus for mediawiki.org changes is checked, hence I'm opening the discussion here.
Also, some users have already started disabling LiquidThreads on some talk pages to use wikitext instead: what to do? Should that be done on more or less pages?
LiquidThreads was an unmitigated disaster, in my view, and has made the site worse for being here. History before it was enabled was lost (or, at least, very hard to find) the links in e-mails never take you to the thread they're supposed to, the UI is horrible and it is difficult to find things you are looking for. It actually makes the site harder to use for anyone at all experienced in wikis, not easier, and so should never have been enabled.
I haven't used Flow, so I don't know how it compares, but I would certainly vote for removing LiquidThreads! If Flow actually works in a wiki-like way (i.e. you can view history, see the state of the page before it was enabled, edit comments where necessary, etc.) then I might be persuaded that it is a good replacement, but given our experience with LiquidThreads I am fairly sceptical. For it to work it would have to be something that works inside existing wiki pages, rather than fighting against them. It would also be a requirement that all LT content can be 'migrated' to Flow so that it is not lost or broken. It is not acceptable for it to simply be shunted off to an 'old threads' namespace and abandoned - it needs to appear where it was originally posted.
The issue is as much about how the extension works behind-the-scenes and how well it integrates with the rest of the wiki, as about the interface it provides.
For example, I don't want to lose my current talk page, nor its history. If what is there can be converted seamlessly to Flow, without losing my ability to view old revisions of the page (pre-flow and post-flow), archive things in the way I have done in the past, include some non-thread-like content (e.g. introduction section) and link to specific items without the links breaking as items change (e.g. if they move to 'page 2' of the listings) then it might be viable. Otherwise, please just remove LiquidThreads and don't mess up the wiki with further incompatible plugins.
PS - From reading the wikitech-l post, it looks like once again this is a decision being forced upon us without any kind of local consensus. MediaWiki.org should not be treated as a test site, without community buy-in. If you want people to be antagonistic towards Flow, and to resent its presence on the wiki, then that is a pretty good way of going about it.
Also, I didn't realise quite how experimental/incomplete Flow currently is. Therefore, my vote is (for now at least) a firm no!
The comment from Risker/Anne sums things up pretty well, as far as I'm concerned.
Please just remove LiquidThreads and come back to us with a proposal for Flow when it is out of beta and feature-complete.
Please no back to plain wikitext talk pages, at least for talk pages with hundreds of posts (like Current_issues and Support_desk). Wikitext talk pages are terrible to follow and archiving is as bad as the wikitext discussion format itself. I prefer LQT (in it's fairly bad state) before wikitext, but i welcome a move to Flow, after it is in a workable state (see, e.g., this mail).
See also[edit | edit source]
- Thread:Project:Support desk/Starting conversion of LiquidThreads to Flow at mediawiki.org
- Topic:Sdoatsbslsafx6lw
So, from my side: 
Support
Is it possible to have a complete list of LQT pages on this wiki? That would help the discussion.
Certainly it makes sense to use modern discussion software on Project:Support desk, as that is a high-traffic forum-style page which is aimed at IT professionals and server administrators more than wiki users.
I agree that for the support desk, and maybe a couple of other support-related pages, a more forum-like approach is sensible.
However, one does have to question why we use the wiki for these purposes at all. We don't use the wiki for internal issue tracking, so I'm not sure why we are using it for support. I am not aware of any other company or open source project that would consider using a wiki for handling support issues - it is clearly the wrong tool for the job.
Perhaps a more sensible solution would be to use support desk software for handling the support desk, rather than trying to shoe-horn non-wiki-like tools into the wiki, which will inevitably bring unsatisfactory results (as has been shown with LQT).
FWIW, there was such a proposal too: phabricator:T31923.
Search is pretty good at finding LQT talk pages: [1].
Special:PagesWithProp also works. [1] - currently LQT is on 1,639 pages - (I'm not sure why that number differs (1,567) from the search that Nemo linked?)
Re: existing posts - currently 52,526 individual posts. Of those: 24,897 of those are in Project:Support_desk; 1,269 in VisualEditor/Feedback.
I'm asking devs for help getting a more detailed listing of All pages ordered by size (number of posts).
[Update: A list of all pages with more than 10 posts, is now at phab:P417, and converted into an onwiki page with links at Flow/LQT pages.]
The Flow/LQT_pages are interesting, thanks. Just for fun I looked at the even (non-talk) namespace numbers: One entry in 90 might be odd (3 contributions counted as 12), and for the Project:Forum redirect I didn't get why it's counted as 94.
Note: We'll be holding an IRC office hour for Flow, this Monday at 19:30 UTC / 12:30 PDT. You can find information on how to get online, including a link to a webchat option if you don't have an IRC client, on the meta office hours page. The intended focus is for questions about the LQT -> Flow conversion here. Everyone is welcome for discussions and question answering. Logs will be posted on the meta office hour page afterwards. Thanks.
Few minutes of testing were enough to discover that
- T93723: Conversion to Flow eats content
- T93721: Links to LiquidThreads threads don't work after conversion to Flow
WMF, please ensure you table such proposals only after you've thoroughly tested the conversion. Thanks.
I don't know if it's just an unfortunate coincidence, or what, but since this announcement, the usability of LQT has degraded a lot...
First I reported that submitting a reply doesn't display the reply unless you refresh the page.
Today hitting "show preview" displays a confirmation dialog about leaving the page, and if you proceed, you end up submitting an edit to the underlying page and not on the message you was editing!
Some time ago I proposed this client. Unfortunately it never got approved and is now listed as "expired", but I'm still interested in it. What am I supposed to do?
Vague ideas, maybe ask one of the OAuth admins what's next after "expired". If you figured it out please add it on the Extension:OAuth page, and/or start a thread on Extension talk:OAuth, and/or tackle the odd m:Meta:OAuth administrators stub.
More to the point, some kind of "identification game" sounds like "bring as many privacy lawyers as the EU has members for an initial informal discussion how to get global community consensus".
Hi,
Just a quick notice, letting you know I'm currently working on a bot that get's documentation from the PHP classes (required rights, must be posted, parameter optional/required + description, examples etc.) into wikitext and saving to a wiki page.
Zak originally created something for this (example), but the source code remains unpublished and the format has changed a lot since then.
Roughly what I've got / aiming for (about 50% done)
- Extract module name/class pairs from
$mainApi = new ApiMain - Loop over and instantiate it:
$module = new $class( $mainApi, $name ); - Buid a documentation page in wikitext format:
new ApiDoc4Wikitext( $module );- {{API-head}} with parameter values from
getModulePrefix,mustBePostedetc. - Parameter section build with a function based on
makeHelpMsgParametersbut in wikitext format - Examples section based on array from
getExamples, which is then dissected into parts for {{ApiEx}}, followed by an http request to exampleurl+format=xmlfm and output cleaned up and unescaped and fed to result-parameter of {{ApiEx}}. - Categories
- {{API-head}} with parameter values from
- Either write wikitext to a file and let another bot save to wiki, or write a simple wikibot and save right away.
To be done:
- Example section
- Saving mechanism
Any ideas / existing code I can look at ?
The source code mentioned above is an empty svn folder. Is it hiding in an archived svn branch, or did it never see the light of day? This is now relatively easy to do with Pywikibot since I added a ParamInfo class. See API_talk:Main_page#Missing_documentation_pages for some basic code.
Does anyone know who Zak is? And/or where this prototype code might be?
Zak was probably the contractor that the foundation hired a few years ago, Once his contact ended he didn't return.
Zak hasn't been around for a while. I knew him when he was here (I had a chance to meet him in Gdansk) but since then he hasn't really been involved.
Thanks Peachey88 and Mark. Is his code lost? Can we contact him? phab:T31936 is related. I cant find much more about it.
I sent him a message on FB. Let's see if he responds.
Greetings All,
Any source code that remains in sitting in storage about 8000km from where I am at the moment. :-/
However, I'm happy to look at source code and otherwise pitch in some.
Cheers! --zak
Note that ApiHelp can now be transcluded, see an example at Extension:Flow/API. I think SPage has plans to start/propose using this feature more widely once it gets possible to select content language à la {{TNT}} (currently it's only possible via interface language change, e.g. [1]).
So far, Special:ApiHelp is extremely ugly (but better than nothing), and the details on Extension:Flow/API are not provided by Special:ApiHelp - they are added by hand. Also there is one aspect of the documentation which can't be generated (currently): information about previous releases. i.e. when each module & parameter was added, deprecated, & removed. Sadly there is not a lot of care for wikis running anything but the bleeding edge.
{{API-head}} has been improved to include a link to the API help module, so the current help is easy to get to, and that template has been added to most of the existing API pages.
My proposal is phab:T89318, John Vandenberg and RobinHood70 raise excellent points. We'll have this tension with any generated documentation, so I mention it in phab:T93026 "remove wiki documentation that duplicates generated documentation (tracking)."
"It gets rebuilt from scratch on every code change" is a feature and a bug :)
Mass vandalism by User:Prianka
This user has used a bot to remove content from pages. Please revert their edits.
@Kaldari: uploaded a new version of File:Wiki.png today. I don't like it. In fact, I thought it was vandalism at first. Can we get this reverted?
I like the idea of using special logos for special milestones and/or events and so on, but maybe it should be discussed first.
Discussion, it's not directly related to Extension:SemanticMustacheFormat, but just in case I "rescued" it.
It would be OK if it was explained somewhere... Most folks won't get such tech-jokes and therefore mistake them for vandalism or at least for a bad joke.
And this logo was used on https://www.wikimedia.org too until a few minutes ago [1]... I'm also not completely against changing logos for special occassions but there is no explanation about why it was changed.. I've checked various places but I still can't find anything about this.
Hmm, https://gerrit.wikimedia.org/r/181708 Okk but can we really have an explanation somewhere; maybe the logo's link could be changed..
Extension:GraphViz The design of the page looks broken. Funny thing is that has been no edit recently.
- Firefox (35.0.1): completely broken
- Chrome (Version 40.0.2214.115 m): same as Firefox
- Internet Exporer: looks awful, especially the top part.
Thanks for reporting this! Seems to be related to recent edits to Template:WikimediaDownload (which is used on that page) to make it translatable. I've dropped a message on the author's talk page as I have no idea what went wrong here exactly... :(
這個頁面應該是繁體中文(Chinese Traditional, zh-hant)文字，為何變成了簡體中文(Chinese Simplified, zh-hans)文字？translatewiki:MediaWiki:Extdist-created-extensions/zh-hant
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.
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.
Hi, please let the first missing Wikimedia Engineering/Report/2015/January explain that the monthly reports are now finished for good, I still had a convoluted [[Wikimedia Engineering/Report/{{#time:Y/F|now-31days}}|Tech report]] for {{#time:F|now-31days}} rendered as "Tech report for January" on my user page.
I've updated three related pages on this side:
- On Wikimedia Engineering/Report/2014 red link "2015" now goes to phabricator:tag/report/
- On Wikimedia Engineering/Report/2015/January phab:T88470 is flagged as "resolved".
- On draft m:Tech/News/2015/10 the issue is noted as "future change" announcing the tag.
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.
> in few minutes? or perhaps next week.
The change isn't in wmf17, unfortunately, so you have to wait until wmf18 or backport the change :)
The bug wasn't fixed yet. :(
Can someone search if a bug was filed? I saw something somewhere about clearGroup, but I can't find a thing in Phabricator.
Nothing that I can find. Please a file a bug about marking page for translation failing with this error.
Could Template:API-head be marked for translation please? (pinging user:Steinsplitter who so often helps me on these matters)
（很抱歉，我不會英語。）
translatewiki那邊早已修正錯誤了，為何這裡還沒有更新？請把搜索改成搜尋，謝謝！
The user claims that translatewiki was changed (in November of 2014) but the change hasn't been reflected here.
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.
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. ;-)
First page |
Previous page |
Next page |
Last page |
