Meta:Babel/Archives/2010-12

Banners

Could we please move Fundraising 2008/web buttons somewhere that does not have a date. I am being asked on OTRS for banners etc., the 2008 date makes it look as if it's specific when actually it's not. JzG 11:19, 29 November 2010 (UTC)

You may want to direct them to https://secure.wikimedia.org/wikipedia/foundation/wiki/Support/en instead, although the old buttons also work fine. Kaldari 02:19, 2 December 2010 (UTC)

Status

Many editors currently use a separate page where they update Online or Offline, and transclude the page to their userpage, in an attempt to create a "custom made" status update feature. As a result, often allocating a big chunk of their edit percentage on that page.

How difficult is it to create an integrated status update feature? Based on my limited knowledge in MediaWiki functions:

  1. Things like Special:Watchlist only open when you are logged in
  2. So based on such "sensing" feature, why not create a dot (on every wiki), which turns green when the user is logged in, and red when not? We could also add text in different languages.
  3. And maybe a little extra work to add custom statuses?
  4. And maybe a special section is Special:Preferences/Editing (see below)?

Due to any MediaWiki limitations, if it is impossible to auto-update this status upon login and logout/browser-close, then we could also base the functionality like a user's watchlist database, where editing your watchlist doesn't really record a history (in Special:Contributions); you click a button to change your status, just like the "star" in the Wikipedia's Vector skin.

But IMO, if it works that way, then the status update has to be global, or else a global-editor has to open all the pages s/he's logged in, and click on signout (or whatever) to appear offline. Or if possible, add a "make status updates global" option in the preferences section mentioned above.

Or, a big fat or, we could somehow integrate a function where, upon clicking [[Special:UserLogout]] (the existing logout button), it would default the status update to "Offline". But then, what about the dudes that close the browser instead of clicking logout (like me)? The same could be done for [[Special:UserLogin]] (the existing login button), with a similar but: what about those who save the login data in their browser (thus closing doesn't signout)?

This feature needs a ton of discussions to put in, that's for sure :) Rehman 00:52, 4 December 2010 (UTC)

Oops, you're right. ;) Rehman 01:37, 4 December 2010 (UTC)
  • "what about the dudes that close the browser instead of clicking logout"? Worse, what about people like me who just walk away from their machine, and leave it on all the time? Perhaps the only practical way to do this is to monitor edits, and declare an editor offline if they haven't edited in, say, 10 minutes, plus allow them to say "I'm leaving right now". Rd232 02:01, 4 December 2010 (UTC)
We could have an "Away" option too. But yeah, the edit monitoring is also a way around... Rehman 02:04, 4 December 2010 (UTC)
It would be nice, if it could be implemented with any degree of accuracy. But it would be preferable to have the user be able to opt in on the preferences tab. I would suggest having 'editing', for when people are actively making edits; 'online', for when people are just browsing, 'huggling', for when people are fighting vandalism; and 'offline', for when people are logged out/not loading/not editing pages. Reaper Eternal 03:09, 4 December 2010 (UTC)
  • Every dozen odd implementations of this have been nixed by the sysadmins. It's a pointless waste of resources, this is an encyclopedia not social networking. OverlordQ 08:31, 4 December 2010 (UTC)
What does showing your status have to do with social networking? This is a particularly useful tool for administrators/sysops who are contacted frequently by other editors. With this, users could select the online user to contact, instead of picking a random and, useless waiting. Rehman 08:34, 4 December 2010 (UTC)
Clarification is needed here. Every implementation of such a system using bots and other methods that are wasting resources like mad have been nixed by the sysadmins. That doesn't mean that some sort of offline/online+livechat feature is never going to be allowed (Actually it was often advised in the strategy process and the Helpdesk/OTRS teams have often requested it as well). It means that someone has to implement a proper solution. Implementing this isn't simple at all btw. It would require several new (separate) servers to support such a feature I'm guessing. Collaborating closely with people like domas, danese and Tim is advised, to make sure your final implementation will be accepted. A jabber service has been pondered several times as the backbone technology for this, but indeed the most difficult part is of course building a proper "action" detection system, status switcher and opt-in/out possibility for the users. TheDJ 18:49, 4 December 2010 (UTC)
  • Dont have a bugzilla account so I'll comment here; Before people/foundation spend resources this should have wide spread discussion. I can see many privacy issues with this you'd find that many sysops, crats, ARBCOM members would want to be able to disable it just be left to do what they want/need to concentrate on. I for one would want to be able to perminently disable it if its implimeted whether I'm online or not is not something that I want broadcasted. Gnangarra 04:06, 5 December 2010 (UTC)
Yes, this feature is just an opt-in feature, which IMO, should be off on default. Rehman 04:15, 5 December 2010 (UTC)

RfC request

Please see User talk:Tyciol#Email: Fri, December 3, 2010 2:04:55 AM.

The user in question is currently locked and wishes for someone to open an RFC regarding the lock and its circumstances. You can still use special:emailuser/Tyciol if you have any questions for him.

I am abstaining due to being an involved party: Specifically, I performed the lock. Thanks. Kylu 22:42, 4 December 2010 (UTC)

LiquidThreads

Any thoughts on enabling LiquidThreads on Meta-Wiki, perhaps on a per-page basis? I think it could be pretty helpful for pages like Foundation wiki feedback. Foundation wiki feedback in particular isn't very well advertised currently (which is easy enough to remedy), but I don't really want to subject donors/potential donors/visitors to the hell that is current talk page editing. Good idea, bad idea, indifferent? --MZMcBride 02:38, 17 November 2010 (UTC)

Please, don't! But we should definitely create a "Comments" or similar namespace on foundationwiki (as on Wikinews) and use LiquidThreads there. Nemo 23:12, 17 November 2010 (UTC)
With all due respect I have to   Oppose. I do not like the system as I personally find lqts a bit confusing and impractical. Moreover the extension has still some unresolved bugs that makes me unconfortable supporting the installation. Perhaps in the future but not now. Thanks, --dferg ☎ talk 23:40, 17 November 2010 (UTC)
I would support Nemo's suggestion of enabling it in a new namespace of wmf: wiki. Helder 16:35, 18 November 2010 (UTC)
This will likely never happen. wikimediafoundation.org has raw HTML enabled and HTML Tidy disabled. It also has restricted account creation. It's much, much more sane (from a security standpoint) to use a separate site for comments, though some tab integration would be nice. The issue is that adding a "comments" tab that links to Foundation wiki feedback would still mean that people would be forced to deal with normal talk page editing, which is unintuitive and generally awful. --MZMcBride 18:38, 20 November 2010 (UTC)
Is it so difficult to limit raw html to main namespace? --Nemo 19:38, 20 November 2010 (UTC)
LQT is good for casual comments by passerby unacquainted with wiki formatting (like the Comments namespace in use by Wikinews). But I have to respectfully   Oppose it be turned on for regular contributors on user/talk pages. I find it makes longer threads disjointed and harder to follow. Standard indentation is so much simpler and easier to read. LQT might be useful for wmf:, dunno if it's technically possible though. Tempodivalse [talk] 22:37, 30 November 2010 (UTC)
As Tempodivalse notes, it is fine for brief exchanges; but I too must   Oppose because it makes extensive or structured discussions cumbersome, it renders page history useless, it does not integrate well with watchlists, and for users with dial-up connections it is simply excruciating. ~ Ningauble 23:08, 5 December 2010 (UTC)

Javascript help

Hello. This thread is related to this. MZM recently added a script at MediaWiki:Common.js. After it added it at least MediaWiki:Common.js/secure.js (which is a script that automatically gives you the links to https: when you're logged in on https:) stopped working. MZMcBride suggested it might be a conflict with my personal monobook.js file. I blanked it and refreshed my caché to see if the problem dissapears, which had not. Can somebody help me? - it is rather tedious to follow links, ie: on requests for permissions or Special:CentralAuth. Thanks in advance. --dferg ☎ talk 16:42, 28 November 2010 (UTC)

It could also be a gadget you might have enabled?
Can you look at your browser's error console (for Firefox this is at Tools --> Error Console) to see if there's anything noteworthy there? --MZMcBride 21:35, 7 December 2010 (UTC)

I had a look at the error console of firefox, which is always giving me the following error: "jQuery.wikieditor is undefined" and highlights the following part of the script you've added.

if ( !jQuery.wikiEditor.isSupported( jQuery.wikiEditor.modules.toolbar ) ) {

Thank you, --dferg ☎ talk 16:42, 11 December 2010 (UTC)

Try making that line if ( 'wikiEditor' in jQuery && !jQuery.wikiEditor.isSupported( jQuery.wikiEditor.modules.toolbar ) ) { maybe? --Catrope 12:05, 12 December 2010 (UTC)
I've changed the line with your suggestion, but it does not work. New errors from firefox error console:
Error:jQuery.wikieditor is undefined
	if ( 'wikiEditor' in jQuery && !jQuery.wikiEditor.isSupported( jQuery.wikiEditor.modules.toolbar ) ) {
Error: jQuery("#wpTextbox1").wikiEditor is not a function
									'pre': '--~~' + '~~'

--dferg ☎ talk 12:17, 12 December 2010 (UTC)

Sorry, I misunderstood what that line did. if ( !( 'wikiEditor' in jQuery ) || !jQuery.wikiEditor.isSupported( jQuery.wikiEditor.modules.toolbar ) ) { should do it. --Catrope 21:10, 12 December 2010 (UTC)
Updated the code at MediaWiki:Common.js. Dferg: Did that fix the problem? --MZMcBride 21:15, 12 December 2010 (UTC)
Catrope, MZMcBride: many thanks for your help. The script is now working for me again. Best regards, --dferg ☎ talk 22:06, 12 December 2010 (UTC)

Just wondering, why is the above page viewable only to admins? What harm could non-admins cause? Rehman 11:58, 8 December 2010 (UTC)

I imagine it's the same situation as "regular" special:userrights ... if you don't have the ability to access it on a wiki (in this case, if you don't have the correct global rights) then it simply won't display. Pages like special:undelete and special:unwatchedpages are restricted similarly. If you want to see what rights someone has, try special:GlobalUsers and enter their name.
I'd note that the GU page is a bit different than special:ListUsers however: ListUsers shows all rights that someone has if you select a group... pick "checkusers" on Meta, for instance, and you can see in that list that someone is also an administrator, bureaucrat, steward, whatever... Visit ListGlobalUsers, however, and select "steward" and you'll see my steward flag, but not the global rollback one. Put in someone's name and don't select a group, however, and you see all their global groups. Strange, isn't it? Kylu 14:06, 8 December 2010 (UTC)
Kylu, this may be worth opening a bug. --Nemo 23:41, 8 December 2010 (UTC)
  Done - please see bugzilla:26427.   — Jeff G. ツ 17:10, 25 December 2010 (UTC)
Just to clarify, it's not only viewable to admins, it's only viewable to stewards (those who can change global user rights). Cbrown1023 talk 23:06, 8 December 2010 (UTC)
Yes, only viewable to those people with the ability to change global user rights: stewards, staff and system administrators. Others who can't change them do not need to access that page I think. I'll modify the MediaWiki message to make it clearer (hopefully) Cheers, --dferg ☎ talk 12:33, 9 December 2010 (UTC)
Minor clarification: not staff. :) Philippe (WMF) 16:44, 11 December 2010 (UTC)
That's true. Fixed & thank you. --dferg ☎ talk 17:11, 11 December 2010 (UTC)