Project:Current issues
 Archives |
Contents
 First page |
 Previous page |
 Next page |
 Last page |
Maybe change contents of mediawiki:revreview-quick-none to something less likely to confuse
Due to flagged revisions, there's a little box on the top of most extension pages saying "unreviewed" (controlled by mediawiki:revreview-quick-none). This could be confusing to people who think it reflects the (code) review state of the actual extension (someone was on irc recently who was confused by it). I think we should change mediawiki:revreview-quick-none to something like "not flagged" to prevent confusion.
/me would do it myself, but I can't edit interface messages.
I can see how a change would cause less confusion. I'm not sure if "not flagged" will be more or less confusing - although it does link to a more detailed explanation...
If there's any consensus on better wording, I'll go ahead and make the change to the interface message.
Perhaps something like "Documentation page unreviewed" ?
Would "Documentation unreviewed" apply to all pages on MW.org including Manual, Extensions, Project and main space? I can't think of any off the top of my head it wouldn't work for...but...
As far as I can see, FlaggedRevs is enabled only on documentation pages, isn't it?
Over the last months I've experienced MediaWiki.org getting more cluttered, different kinds of content being mixed. As a result I find that things are harder to find and more separated than they should be. Also causes more confusion and potential duplication.
I attempted to get a good overview of what is currently on this wiki which I'd like to use as a starting point to see if there's anything that shouldn't be on this wiki, or things that should be more separated away.
Check out User:Krinkle/Content structure, and links from there.
For example, there is MoodBar (WMF Project page, with /status, /Design etc.) and Extension:MoodBar (Documentation for end-users). However this distinction does not exist for ResourceLoader, which I think is a problem. I'd like the WMF project related stuff to be separated from the documentation about the feature.
Also documentation in general is getting worse and more decentralized at a rapid speed. Are we going for auto-generated documentation ? Or not. If so, do we want this to go into wiki pages and be editable on the wiki, or perhaps as an extension through Special:Documentation ?
The documentation thing is kind of a separate project though, more on that at Requests for comment/Documentation overhaul
I would support a discussion on this and would be willing to help with any concept development or eventual implementation. It's clear this is a topic which needs to be addressed on some level - this seems like a reasonable way/place to start. :)
Given the subject, it's ironic that your policy proposal has been placed in the user namespace, rather than the project namespace! :-)
I agree that there are big problems at the moment. Thanks for categorising the current state-of-affairs. It's a good starting point for discussion. I want to check that you've seen Project:Namespaces, which gives an overview of how things were originally set up. I think that the current namespace structure pretty much holds, and the problem is that we are seeing drift caused by a couple of factors:
- There is a lot more drafting and discussion about work-in-progress happening here.
- Stuff relating to WMF deployment/servers/meetings/etc. and features that are predominantly for WMF purposes used to be documented at Meta, but are now being documented here.
- New stuff is added to and changed in the software all the time (hooks/settings/features/etc.), but the documentation on this site is not often updated (or if it is, it is not done thoroughly or well).
- When I first structured the site, a number of years ago now, the focus was nearly exclusively on documenting the existing software, so it was pretty clear where things should go. However, it is not so easy to compartmentalise things now - it is harder to know whether something is considered 'developer discussion' or 'documentation' - so people don't know where to put things. The majority of new material now seems to be planning for future software. Planning (under the current structure, at least) is something that belongs in the main namespace, but is all-too-often placed in the User or Manual namespace. However, once the feature is implemented there are parts that should be moved into the Manual (documentation) namespace, and parts that should stay where they were. It is not always clear when or how these should be moved, and in general it doesn't happen.
- There are very few people who are actively maintaining the site, and those that do either don't have the knowledge, or feel that they don't have the authority to move or refactor things, particularly when content is coming from sources that are pretty god-like in the developer community (but who may know nothing about how MW should be structured, and care even less). So even if it is clearer where things should go, the bit-rot is still likely to set in unless there are more hands to the pumps. A clearer policy would help with this.
Just my initial thoughts - thanks for opening up the discussion.
This: Extension:Semantic Maps extension's page points at a dead domain "mapping.referata.com" (see below). A WHOIS shows it is registered until 20 April 1012.
However this means that the only way of finding docs is via Google cache or similar. The discussion page is locked as well. Could the project status be updated in some way? Perhaps a note could be put in to warn new users that they might be in for a rough ride!
Cheers Jon
dig @8.8.8.8 referata.com ANY ; <<>> DiG 9.8.1 <<>> @8.8.8.8 referata.com ANY ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54721 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;referata.com. IN ANY ;; Query time: 2515 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Fri Jan 20 16:44:55 2012 ;; MSG SIZE rcvd: 30
Hi. I am trying to remove my name from the page, 'Jake Fajzullin', from the page: http://wiki.tell.com/index.php/Whatever_(slang) It's a long story but I desperately need to remove my name from the page. I have searched the 'tell wiki' website and can't find a way to edit the page nor contact 'tell wiki' about my request. I saw the page is powered by mediawiki and am hoping someone here can help me out with getting my name removed. Please help, I would really appreciate it.
Thanks, Jake
Wondering if there's a current procedure in place for "closing" a support ticket in Project:Support desk. It seems as though it would be valuable to have the ability to glance at the list and know which are resolved and which are open-ended. So I propose that any user involved in the conversation can close a ticket if the issue has been resolved. If it is prematurely closed ("oops - that didn't work after all") that same person, or a different person involved (like the original poster in this example) could change it back, if need be (although I suspect that would be rare).
In cases where it's not clear - like a solution was offered but no response to confirm it worked - I think we can close a ticket if it's been left unedited for 14 (7?) days and if a workable solution was posted.
We can also use these changes to note other ramifications like "[Resolved - bug 1234 created]" or "[Resolved - added to Manual:FAQ]".
Any feedback? If no objections, propose we implement this in a week (time for discourse). I can write up a page explaining it a bit more. Doesn't have to be a "required policy" but a best practice - unless folks feel more strongly about this than I do. :)
Looks like a possible use for the Summary field in LiquidThreads. I've done an example on this thread.
That's a good idea! Do you think there are instances when folks would only glance at the TOC or can we safely assume they'll browse down the page?
Well, this is how it usually works on wikis, except that you can't archive resolved issues. How LQT should be used is quite a mystery, see bugzilla:24815.
I think for the time being I'm going to propose a combination of the two. At the very least a comment added - but an update to subject if the person doing the maintenance is feeling frisky.
Adding a comment to mark something as closed, if you didn't actually do anything, it's a waste of other people's time because/if it bumps the thread etc.
In particular special pages, which might not exist here? See Template_talk:Mediawiki#Special_pages. As far as I understand the Help: namespace should be possible to export in any wiki and work as is (but does anyone actually do so??).
I'd like to merge the contents from Meta's MediaWiki FAQ into Manual:FAQ. There's a notice on Meta that mentions a MW.org admin should be involved with any such merger to import that page's history. Are there any admins that would be willing to assist me with this effort? Thank you! :)
I tried to do the import so you could start working on it, but it keeps failing with a blank page and a partial import. This needs looking into by someone higher up the technical chain. It is probably (though not definitely) a time-out issue. Or perhaps just a bug. There are about 1500 revisions in the history, which are mostly quite large, I expect.
I don't have time to prod people about this, but your best bet is either to ask on IRC or to post a bug on Bugzilla.
I'll keep watching this thread, and will be happy to have another go at the import once the problem has been fixed, if no-one else does it first.
Cheers,
Oh yeah, We talked about this on IRC, I believe we just decided to soft-redirect it since we already have most of what is already in it compared to worrying about transwiki and histmerging it into ours.
Looking at instances of #babel and Template:Babel on MW.org pages, it appears the categories are not setup in MW.org's LocalSettings.php to allow for its actual use on MW.org. My guess is it was customized for displaying purposes on MW.org so they wouldn't categorize help pages, etc. Is there a no cats parameter for Babel that could be used instead, or perhaps one added. Seems like it would be good to have the categorizing of users by language being used on MW.org - but perhaps that particular feature is not really needed?
The community here never really cared about the babel templates, which is why they were never really created or cared about. The extension is really only active here because it was pushed out and onto everyone and we didn't have any pre-existing categories for the templates which is why they weren't set-up when the extension was activated. But if there anyone actually had a desire to see it up and running on here I wouldn't see that many people complaining about it.
I wouldn't mind finishing the setup if it were fully enabled.
There was some discussion about this a long while ago, where it was decided that this wasn't really necessary on MediaWiki. Due to the nature of the wiki, it's content and the way it is used, it was felt not only to be 'not useful' but also, possibly, damaging due to the extra clutter.
Unfortunately, since the crappy Liquid Threads was installed, which messed everything up, it is impossible to locate the history for any pre-LT discussions, so I can't point you to it.
I suspect this situation still applies, but if you really think it's worthwhile (rather than just doing it 'because we can') then I don't feel too strongly, personally.
"impossible to find"… Clicking archive links is hard or the search function?
Are these the discussions are you talking about? Project:Current_issues/Archive_2#Babel Project:Forum/archive/2008#Babel_equivalents.3F
This page may not be sighted (give it a try) since access is denied. It would be cool if someone will have a look at this. Probably Siebrand has already addressed it somewhere, so this is just to make sure ... Thank you and cheers
Merging Installation and Manual:Installation guide
Since it appears a majority of Installation's content is already on the landing page for the Manual:Installation guide, any objections to my merging Installation into the guide's landing page? That would include placing whatever content doesn't already exist on the landing page either within it or clearly linked to its appropriate subpage (requirements as an example).
Restoring Extension:AgFeed
Hi, in may of this year the extensions page was deleted. However the download is now availabel at http://www.nozicaa.com/fr/page.content/T%C3%A9l%C3%A9chargements#VisualMathCaptcha Thank you and cheers
I suggest to move all source codes from main extension pages to subpages. It would allow easier updating source code and less wikicode size when editing page itself.
I recently had a bot flagged only to find that it can't move pages because it's not autoconfirmed, that's not a big deal for me personally and I can do the job by hand or wait; however, the fact that no one has the ability to add the bot to the group "confirmed users" so that it can move or upload is problematic, since by the very nature of bots, they have an operator who is trusted or they wouldn't get a flag - they also frequently, as with my bot, only have an account on mw once there's a need for them. I think we should either add the relevant rights to bots OR authorize admins or crats to promote users to confirmed. I think the latter would be best and the requirements for promotion should be that the user either 1) is a trusted user on another wmf project or 2) is a bot controlled by a trusted user. Therefore, I propose giving admins the ability to add users to the group "Confirmed users".
On a related issue, I found that there is an 'autochecked' userright that admins can grant but the right is undefined. I'm told that this is related to flagged revisions, though I haven't seen it in the default set up on other wmf projects. I intend to submit a bugzilla to remove or define this right.
Can't we just give the necessary rights to the bot group? I don't think we want to deal with requests for yet another permission. By the time we handle someone's request for confirmation, they'll probably already be autoconfirmed.
Though I'm wondering if we'd want to also give the rights to, say, editors. I mean, for example, say that Phe didn't have the 16 edits that he has here; would we really make him wait four days to move a page or upload something? (And for that matter, there's a developer with only 25 edits on mediawiki.org.)
I think that it would make sense to redirect it to Template:Documentation needed: the scope is similar and this would help users finding it.
up :-) [yes, I hate LQT and I'll abuse them as forums are abused]
[21.10.2011 17:03:17] JavaScript - http://www.mediawiki.org/w/index.php?title=Project:Current_issues&action=submit Inline script thread Uncaught exception: ReferenceError: Undefined variable: jQuery Error thrown at line 37, column 0 in http://www.mediawiki.org/w/index.php?title=Special:BannerController&cache=/cn.js&303-4: ( function( $ ) {
Currently, all JavaScript on mediawiki.org is broken when using the Opera web browser. I was able to track the problem down to Special:BannerController. In the last line it depends on a variable jQuery that does not exists (at least when using Opera). The script crashs and no other script is executed. Due to this error the coding challenge page is broken.
What version of Opera, on what operating system? I see no obvious problems under Opera 11.52 (current release) on Mac OS X 10.7 which I have handy.
I do recall hearing something about there possibly being a problem on old versions of Opera that jQuery no longer supports; might you be running one of these versions? We'll need to check the fallback behavior and see what's going on...
Happened in the current Opera 11.52, running on Windows 7 behind a company firewall. It worked in Firefox 7 on the same machine. At the moment, I can not reproduce it. On an other machine (and other network) it works in all browsers, including Opera.
I found the error. It happens with the NoAds Opera extension installed and active. In the last step of your "startup" module this line is executed:
document.write("\x3cscript src=\"//bits.wikimedia.org/www.mediawiki.org/load.php?debug=true\x26amp;lang=en\x26amp;modules=jquery%2Cmediawiki\x26amp;only=scripts\x26amp;skin=vector\x26amp;version=20111007T213533Z\"\x3e\x3c/script\x3e");
This line is blocked by the extension. But it is not blocked at wikipedia.org. Why not? My answer: There is a difference in both scripts. At the end of the line shown above this part is missing:
type=\"text/javascript\"
Please add this.
PS: The function linkedScript() in Html.php does not output the type attribute in HTML5 mode. Why not? Please always output the type attribute for compatibility reasons, even if it's the default value type="text/javascript". It's not wrong to do this according to the spec.
PPS: Reported at bugzilla:31920.
PPPS: I'm sorry. I was sure I found the reason but adding type="text/javascript" does not help. Still a strange bug. No problem at de.wikipedia.org with this (bad) extension enabled. I think I will look for an other extension that's better maintained.
PPPPS: Same problem with an other extension. The reason is pretty simple: It blocks all external scripts. wikipedia.org is on the default white list that comes with the extension. mediawiki.org is not on the white list. That's the difference.
PPPPPS: How do I edit the wrong date under this post? --TMg 00:00, 25 October 2011 (UTC)
The absence of the type-attribute is unlikely a problem. One of the reasons it was safely removed in HTML5 is because older browsers (even those without special HTML5 support) already defaulted to 'text/javascript').
If you think it is the problem though, feel free to check out MediaWiki and see if it works if you re-add that attribute in a local patch.
https://bugzilla.wikimedia.org/show_bug.cgi?id=29596 Thread:Project:Support desk/incategory does not work? Extension:Lucene-search
the function incategory doesn't work in the french wiktionary site. can anyone work on it?
It's because the category is included from a template. Its a known issue (see w:help:Search)
What should we do to solve the problem? Would it be difficult to take the categories out of their templates?
From a pragmatic point of view, I don't think the benefits outweigh the cost of removing cats from templates.
This issue might go away when/if bugzilla:18861 is fixed. In the mean time you can also use tools like http://toolserver.org/~daniel/WikiSense/CategoryIntersect.php?wikilang=en&wikifam=.wiktionary.org&userlang=en to do in category searches.
First page |
Previous page |
Next page |
Last page |
