Wikipedia:Village pump (technical): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 16:48, 30 April 2013

Table of contents
First discussion
End of page
New post

Shortcuts

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (How to report a bug). Bugs with security implications should be reported to security

wikimedia.org.

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

view · edit

Frequently asked questions (see also: Wikipedia:Technical FAQ)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

H.264 support

Tracked in Phabricator
Task T41869

Developments since Google reneged on dropping H.264 two years ago, possibly due to acquiring Motorola patents:

Wikimedia rolls out TimedMediaHandler supporting H.264 transcoding
WMF releases iPad app without Ogg or WebM support
Mozilla will support H.264 when the underlying platform supports it
Debian 7.0 "Wheezy" will decode H.264 media out of the box

Now that every modern platform supports it, so we're too late to pressure anyone into switching. So I suggest three transition phases: 1) Allow H.264 files masquerading as ogv/webm, 2) Allow uploading of H.264 and .mp4 extensions, 3) Enable transcoding to H.264. — Dispenser 05:38, 19 April 2013 (UTC)[reply]

This was never about pressuring anyone into switching. It's about Free and open information systems and not opening up ourselves to potential lawsuits by big techonlogy owners. Note that unlike for Mozilla for instance, we ARE part of those underlying systems (esp when it comes to transcoding), so there is quite a different risk assessment. —TheDJ (talk • contribs) 10:34, 19 April 2013 (UTC)[reply]

My post was to inform that all major platforms support H.264 video decoding, even Firefox on Debian the corner stop FOSS. H.264 is a "free" and open video codec, but patented (just like GIF). For the US, not even the oldest codec MPEG-1 (1992) is not patent free, and only more patent landmines have been laid. And even when Google purchases license from MPEG LA for everyone, it still doesn't the stop lawsuits. — Dispenser 23:03, 24 April 2013 (UTC)[reply]

Beyond the issues with proprietary formats, allowing "masqueraded" mime types seems very unwise. I have categorized those to be converted (some already have been), and filed bugzilla:47709 about those even making it to the site. Finally, GIF has never been free and open. Superm401 - Talk 08:06, 26 April 2013 (UTC)[reply]

Hasn't GIF been "free" since the patents expired in 2006? Anomie ⚔ 21:27, 27 April 2013 (UTC)[reply]

Copyright violation box

Dear tech people:

When I am reviewing articles at the Afc, I sometimes come across copyright violations. When I decline a submission for this reason, the dialogue box asks for the URL that has been copied. There's a box to type or paste it in, but it's very small. It's hard to tell if the URL has been entered correctly. Could the box be made wider so that more of the URL would show on the screen? —Anne Delong (talk) 00:30, 21 April 2013 (UTC)[reply]

I guess this is about MediaWiki:Gadget-afchelper.js. You can post to Wikipedia:WikiProject Articles for creation/Helper script/Development page#Feedback. PrimeHunter (talk) 00:39, 21 April 2013 (UTC)[reply]

With URLs I usually right click and open in new tab from the edit preview to see if the link goes to the correct site page.--Canoe1967 (talk) 01:24, 21 April 2013 (UTC)[reply]

I am not sure what you mean. Do you first decline the copyright infringement, and then right click on the URL in the resulting notice? If so, I would prefer to catch the error at an earlier stage. —Anne Delong (talk) 12:30, 21 April 2013 (UTC)[reply]

I have left a message as suggested. —Anne Delong (talk) 12:39, 21 April 2013 (UTC)[reply]

I have never seen the decline/accept edit screen. I was referring to when I do a regular edit and want to check wikilinks and urls. They can be right-clicked from the preview of the edit section.--Canoe1967 (talk) 13:39, 23 April 2013 (UTC)[reply]

Unfortunately, when working in the Afc script there is no preview. Back to my original question, can the entry box for the copyright violation URL be made longer? There's plenty of space in the pop-up box. If no one here knows, can you direct me where to ask? —Anne Delong (talk) 14:34, 27 April 2013 (UTC)[reply]

MY WISH HAS BEEN GRANTED! Thanks to whomever took care of it. —Anne Delong (talk) 03:58, 30 April 2013 (UTC)[reply]

That was mabdul in response to [1] at Wikipedia:WikiProject Articles for creation/Helper script/Development page. PrimeHunter (talk) 10:22, 30 April 2013 (UTC)[reply]

Technical proposal idea for the watchlist

While I was in the process of scanning for vandalism in my watchlist, I realized that I was having difficulty looking through my watchlist for vandalism due to the fact that all of the talk pages that I have on my watchlist are showing up as well. In effect, I had a thought, a thought I would like to run through this forum before starting some sort of "official" proposal, since I am under the assumption that this request might require the filing of a bug of some sort...

How feasible would it be to add a "Hide talk page edits" option to the watchlist? Steel1943 (talk) 05:14, 21 April 2013 (UTC)[reply]

Well, you can change it to look for specific namespaces; the default is "All". Just set it to "(Article)" and that'd be what you're asking for, I believe. EVula // talk // ☯ // 05:16, 21 April 2013 (UTC)[reply]

Not completely. That option only allows viewing of the pages in the "Article" space. I'm looking for an option that allows viewing of all spaces that do not have "talk" in their names all at once. Steel1943 (talk) 05:35, 21 April 2013 (UTC)[reply]

A smarter editor than I would be able to tweak User:Markhurd/hidetopcontrib.js, I bet. ~ Amory (u • t • c) 03:47, 23 April 2013 (UTC)[reply]

You can select a namespace and then invert the selection. This may help; i.e., it allows you to exclude all pages in the Talk namespace. --MZMcBride (talk) 21:33, 26 April 2013 (UTC)[reply]

Articles load improperly on Kindle

Tracked in Phabricator
Task T49499

Recently, I've noticed that articles no longer load properly on the older "paperwhite" Kindle that I often use. Just as an article completes loading the page disappears and only the search box with a left-arrow icon remain on screen. If the arrow is clicked the article will then reappear. This happens on every article every time. Have there been some recent global change to the underlying article markup or style sheet? TenebrisCaelo (talk) 18:59, 21 April 2013 (UTC)[reply]

Yes there have been changes, thank you for reporting this. Can you get more specific version information on your Kindle ? That would be helpful for the devs. —TheDJ (talk • contribs) 08:03, 22 April 2013 (UTC)[reply]

Picked a random article, and Bass guitar looks good on both the Kindle 3 and Kindle Fire. GoingBatty (talk) 23:52, 23 April 2013 (UTC)[reply]

It is called "Kindle 3" I believe, version 3.2.1; although in reviewing the bugzilla discussion, it appears that the problem has been found and corrected. This matches the behavior I noticed when I checked earlier today, every article I visited loaded properly. TenebrisCaelo (talk) 01:13, 26 April 2013 (UTC)[reply]

A "refreshing" change to the CAPTCHA

Hi all,

Forgive my punning. This an announcement about a new feature associated with the CAPTCHA, namely a small link to refresh the CAPTCHA image without having to fully refresh the page. It looks like the screenshots to the right, and will appear everywhere that the CAPTCHA happens: account creation, the login form (if you fail too many times), and on the edit form given certain cases (like submitting an external link as an IP).

We anticipate that we'll deploy this update Thursday the 25th, barring any last minute technical issues. This is a global change affecting all wikis, but I wanted to drop a special note here because as far as I know, English Wikipedia has the highest rate of account creation requests, of which no small amount are due to an unreadable CAPTCHA. I am sincerely hoping that giving users to cycle through images at a reasonable rate without needing to submit their entire signup form again and again will reduce frustration, and perhaps even the queue for account creators. You can see even from the preceding VPT thread that people find our CAPTCHA annoying...

Many thanks, Steven Walling (WMF) • talk 21:31, 22 April 2013 (UTC)[reply]

Nice to finally see this. I'm wondering about the usability aspect of it however. 'Refresh' is rather vague (refresh what?). This is made worse because the element you are refreshing is actually to the left and above the refresh control, which is positioned in line with the inputbox, giving the user the impression it is part of the input box context rather than the 'captcha image' context. something to consider ? —TheDJ (talk • contribs) 21:40, 22 April 2013 (UTC)[reply]

Refresh, plus the icon, is fairly universally understood term. I agree the placement of the button isn't perfect, but it's very close, and the reason it's not closer to the image is because of the rather stupid way that FancyCaptcha spits out HTML for the whole thing. The number one place the CAPTCHA is seen is during account creation (so far as I can tell). In our upcoming redesign of that (mockup), we've improved the placement using borders and background color to more clearly associate the refresh with the CAPTCHA. Steven Walling (WMF) • talk 21:47, 22 April 2013 (UTC)[reply]

If the mockup is where we are going, then I'm good ! —TheDJ (talk • contribs) 07:52, 23 April 2013 (UTC)[reply]

I filed bugzilla:47713 for the placement point TheDJ raised above. Superm401 - Talk 08:43, 26 April 2013 (UTC)[reply]

Will there be some reasonable limit to the number of times the "refresh" link can be used, to prevent this from being a vector for brute-forcing (ie for a bot to keep on "refreshing" the CAPTCHA over and over until it finds one it can OCR, thus escaping the usual login attempt throttling)? -- The Anome (talk) 08:02, 23 April 2013 (UTC)[reply]

A better question would be: is there any reason to believe these CAPTCHAs are effective at preventing spam? Unlike reCAPTCHA and other implementations, the CAPTCHA used on Wikimedia wikis involves concatenating two common English words using a small, publicly accessible dictionary. The bots are undoubtedly trained to submit a best guess. If the answer is wrong, the CAPTCHA is automatically refreshed post-submit. This presumes that humans aren't being employed to solve the CAPTCHA. If that's the case, it becomes even more useless (arguably actively harmful if it's then only preventing the blind and having no impact on spammers). --MZMcBride (talk) 15:35, 23 April 2013 (UTC)[reply]

Anome: we got a review pre-merge of this change from Chris Steipp, the security engineer at WMF, and we agreed with that the throttling should be added outside/regardless of the refresh action, so it has the same effect on manual page refresh. As MZ points out, we have good reasons to suspect our CAPTCHAs are already a pretty weak first line of defense that cause a lot of people grief, and in fact we should probably test our assumptions in this matter at some point. But regardless of the current state of affairs regarding how effective the CAPTCHA is, this enhancement is for humans, many of whom find our CAPTCHAs incredibly frustrating. Steven Walling (WMF) • talk 16:51, 23 April 2013 (UTC)[reply]

Done This is deployed and live now. All seems kosher, but speak up if you catch any errors and we'll file the necessary bugs. Steven Walling (WMF) • talk 22:40, 25 April 2013 (UTC)[reply]

Score !!

Tracked in Phabricator
Task T2189
Resolved

Tracked in Phabricator
Task T49534

After many years, one of the most voted and oldest feature requests has been solved. As of today, Wikipedia finally has a renderer for music notation. See Mark's sandbox for an example. Congrats to the original filer xmlizer ! And a thank you to all who helped write the various generations of the extension and those that reviewed the code. —TheDJ (talk • contribs) 08:35, 23 April 2013 (UTC)[reply]

More at Help:Wiki markup#Musical notation. --Redrose64 (talk) 10:18, 23 April 2013 (UTC)[reply]

There is also a Wikibook in French which could be translated and added to English Wikibooks: b:fr:Introduction à LilyPond. Helder 13:13, 24 April 2013 (UTC)[reply]

Is this working? I tried adding the following code to Première rhapsodie:

<score raw=1>
\version "2.11.63"

\score {
  <<
    \new Staff="clar" \relative c'' {
      \clef treble
      \numericTimeSignature
      \time 4/4
      \key aes \major
      
      \mark \markup {\bold \small "Reveusement lent"} 
      R1 | r4 g\p_\markup {\italic \small "doux et expressif"}( bes c)
    }
    
    \new PianoStaff {
      <<
        \new Staff="one" \relative c'' {
          \clef treble
          \key ges \major 
          \numericTimeSignature
          \time 4/4
          
          r4\pp
          << { f2( f'4~) | f1 } \\
             { f,2.~ | f1 } \\
             { s2. | \times 2/3 { e'8\>( ees c~) } c2.\! } >>
        }
        
        \new Staff="two" \relative c' {
          \clef treble
          \key ges \major
          \numericTimeSignature
          \time 4/4
          
          << { f1--~ | f1 } \\
             { s1 | \times 2/3 { e8\>( ees c~) } c2.\! } >>
        }
      >>
    }
  >>
}
</score>

but it failed with the error

Processing `/tmp/MWLP.926c7a5f74a89391d70986be99418a50/file.ly'
Parsing...
Interpreting music... 
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `file.ps'...
Converting to PNG...GS exited with status: 9ERROR: In procedure delete-file:
ERROR: No such file or directory

Or is raw=1 not supported here? --SarekOfVulcan (talk) 16:16, 24 April 2013 (UTC)[reply]

raw is supported.—Emil J. 16:47, 24 April 2013 (UTC)[reply]

[[here says that raw would be used with lang="lilypond". But is estrange that no mark what error is here get an error after put a r8 and I don't know why. Is possible that have a bug in extension? --88.8.254.79 (talk) 16:11, 29 April 2013 (UTC)[reply]

lang="lilypond" is the default, it is not necessary to specify it explicitly. A simple test with raw=1 works fine:

<score raw="1">
\version "2.14.2"
\header { tagline = "" }
\score { \relative c' { c d e f } \layout { } \midi { } }
</score>

$\version "2.14.2" \header { tagline = "" } \score { \relative c' { c d e f } \layout { } \midi { } }$

The error messages in both your and SOV’s examples suggest that the music was laid out all right, but the final conversion of the output from PostScript to PNG failed. This could indicate a problem with ghostscript rather than with lilypond proper.—Emil J. 16:31, 29 April 2013 (UTC)[reply]

FWIW, Ghostscript’s exit status 9 is invalid file access. There may be a problem with paths or file permissions. This should be reported to bugzilla, but I think it would be helpful if someone knowledgeable with lilypond syntax could make a simplified minimal example triggering the bug.—Emil J. 16:59, 29 April 2013 (UTC)[reply]

Twinkle not installed?

I can't seem to be able to use Twinkle on my Wikipedia account. I checked the box that says "Twinkle" in My Prefrences under Gadgets but there still is no TW at the top of articles. The page User:Missionedit/twinkleoptions.js does not exist and WP:Twinkle/Preferences says that Twinkle must be installed in order for me to change my Twinkle prefrences. I tryed purging my catche with no effect. I am using Internet Explorer version 8. Can you help? ~ Anastasia (talk) 19:57, 23 April 2013 (UTC)[reply]

And there's your problem, Twinkle doesn't work with IE8 or earlier. If you want to use it with IE you need to upgrade to IE9 or 10 or switch to another browser. NtheP (talk) 20:04, 23 April 2013 (UTC)[reply]

Oh, well there you have it. Thanks so much! ~ Anastasia (talk) 00:23, 24 April 2013 (UTC)[reply]

Can the preferences page be made sensitive to this to gray out and add an explanatory comment to the enabling checkbox when the user isn't running a compatible browser? —[AlanM1(talk)]— 20:26, 24 April 2013 (UTC)[reply]

WP:TW already states that Twinkle doesn't work in IE8. To get to WP:TWPREFS, you have to go via WP:TW, so this seems like it should be enough. — This, that and the other (talk) 06:34, 26 April 2013 (UTC)[reply]

Deleted special page and skins

Hello,

I have noticed over the past few days that this page does not exist. I managed to view it recently, and it can still be viewed on some smaller wikipedias.

I also have noticed that a few skins, such as nostalgia and amethyst, have been deleted too.

Why were they deleted?

Thank you! --The Million Rabbit 02:54, 24 April 2013 (UTC)[reply]

I believe I read that the Active Users page was too demanding on server resources. Those skins were eliminated so that fewer skins have to be supported when it comes to new features. Chris857 (talk) 03:48, 24 April 2013 (UTC)[reply]

Re Special:ActiveUsers - I can't find the discussion, but I definitely saw one, and it's basically what Chris857 said. Re skins - see also Wikipedia:Village pump (technical)/Archive 110#Classic skin and CSS and MediaWiki talk:Common.css#Obsolete skin files; I think there were others. --Redrose64 (talk) 07:09, 24 April 2013 (UTC)[reply]

For Special:ActiveUsers see also bugzilla:41078. --AKlapper (WMF) (talk) 10:11, 24 April 2013 (UTC)[reply]

Thank you for your answers. Should the skins be deleted from other wikipedias? --The Million Rabbit 02:58, 26 April 2013 (UTC)[reply]

Hanging userpages

Tracked in Phabricator
Task T49457

I'm getting an odd effect when trying to access pages in userspace (doesn't affect any other namespace). The pages load, then appear to attempt to refresh, but do so unsuccessfully, leaving the browser hanging. Stoping the page load and hitting the Back button takes me to the correct page. I'm running Firefox 5.0.1. Anyone else spotted this, or know of a solution to it? Yunshui 雲‍水 08:01, 24 April 2013 (UTC)[reply]

Seems like the same issue as on Commons. It's reported, will take some time before it's actionable I think. —TheDJ (talk • contribs) 08:26, 24 April 2013 (UTC)[reply]

One fix on commons was to disable the wikilove option in prefs and another was right-click and open new window (not tab).--Canoe1967 (talk) 08:29, 24 April 2013 (UTC)[reply]

Wikimedia developers are working on this and trying to find the culprit, but haven't succeeded so far. See the bug report that was linked by TheDJ. --AKlapper (WMF) (talk) 10:12, 24 April 2013 (UTC)[reply]

While logged in with Firefox 20.0.1 it is not possible for me to open User:TheDJ and User:AKlapper (WMF) in new tabs on English Wikipedia. I can open User:Yunshui and User:Canoe1967 in new tabs. These are users commenting in this thread. I can open them all in the same tab without problems. (Note for techs working on this: I am using https and not http).

The Commons discussion is here: Commons:Village pump#April 21.

The problem is solved when i uncheck "Enable showing appreciation for other users with the WikiLove tab" in my preferences here: Special:Preferences#mw-prefsection-misc. --Timeshifter (talk) 13:12, 24 April 2013 (UTC)[reply]

I believe this is the hanging resolvable by hitting the back button on my browser that I came here to report. I haven't noticed its being restricted to userspace pages, though. (Good that it's been reported, since I found it impossible to figure out what versions of my OS and browser I'm using - Win7 and Firefox something something). Yngvadottir (talk) 18:06, 24 April 2013 (UTC)[reply]

Cannot edit user talk pages - but fine elsewhere

At first I thought this was a browser issue, but seeing as my issue is limited to user talk pages only, it may not be...basically, I cannot edit user talk pages. I cannot even access them. As soon as I click on them I get half-a-second of normal display, before the screen goes blank. Mainspace? Fine. Other talk pages? Fine. User talk pages? No chance. Very odd. Help appreciated. Giant Snowman 13:08, 24 April 2013 (UTC)[reply]

See #Hanging userpages, above. If you have Wikilove enabled, try turning that off. -- John of Reading (talk) 13:21, 24 April 2013 (UTC)[reply]

Perfect, thanks. Giant Snowman 13:47, 24 April 2013 (UTC)[reply]

Unable to view user talk pages in firefox (problem with bits.wikimedia.org?)

Today I am unable to view most pages in the user talk namespace (other than my own talk page) - I get a brief flash of then page and then just a blank page while it apparently tries to "Read bits.wikimedia.org" according to the status bar, but the page never completes loading.

This is only happening in Firefox (20.0 on Xubuntu linux) and works fine in Konqueror and Links (the only other browsers I have access to) and is a new problem since last night when it was working fine (e.g. I was able to leave a message at User talk:CACook7).

I do run the NoScript extension but wikipedia.org and wikimedia.org are whitelisted, the script shows no blocked elements and temporarily disabling it does not make a difference. I am able to load the bits.wikimedia.org page (which redirects to www.wikimedia.org) without any issues. Thryduulf (talk) 15:16, 24 April 2013 (UTC)[reply]

Look up two or three sections for other reports of this. If you have Wikilove enabled, try disabling it. -- John of Reading (talk) 15:26, 24 April 2013 (UTC)[reply]

Thanks, disabling wikilove appears to have solved the problem. Thryduulf (talk) 15:30, 24 April 2013 (UTC)[reply]

#Hanging userpages -- You can be happy that you are an en.wp user. Obviously en.wp is more important than Commons. After AKlapper found the posts here, he changed the bugs relating to highest prio. This is the usual attitude towards Commons users. We get their test software first and if we find issues they are not important until they appear here. -- Rillke (talk) 15:32, 24 April 2013 (UTC)[reply]

I haven't been able to view lots of user talk pages today, but it is perfectly possible to edit the same pages (by manually adding "?action=edit" at the end of the URL). The wikilove icon is present on the edit page too, so why is the edit form still working? --Stefan2 (talk) 22:30, 24 April 2013 (UTC)[reply]

It's not just Firefox - I'm having the same problem with some user talk pages with IE9. Mine seems to be fine, as is User talk:Okeyes (WMF) and User talk:Rillke. However, I see the problem on User talk:Thryduulf and User talk:John of Reading. GoingBatty (talk) 23:55, 24 April 2013 (UTC)[reply]

Confirmed that disabling the WikiLove extension fixes the issue. GoingBatty (talk) 00:01, 25 April 2013 (UTC)[reply]

Worked for me too - thanks to all the above for identifying disabling WikiLove as a temp fix. -- stillnotelf is invisible 15:19, 25 April 2013 (UTC)[reply]

Thanks for the explanation. Is there any way to sign for a notification of when this problem is solved so that WikiLove can be reenabled? I find it very helpful in building a collegial, friendly atmosphere. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 03:51, 25 April 2013 (UTC)[reply]

You could add your email address to the bug's cc list. That will send you an email every time there is a change to that bug, including a new comment, which is isn't quite what you are after. The only other thing I can think of is that I can try to remember to put a note on your talkpage when I see it's been fixed, but I can't promise to remember or to be online when it happens. Thryduulf (talk) 09:26, 25 April 2013 (UTC)[reply]

Fixed

We have deployed a change that should fix this problem, and have re-enabled WikiLove. If you see any more problems along these lines, please reply here, or at Template:Bug, or at #wikimedia-tech ^connect. Thanks. BJorsch (WMF) (talk) 23:22, 29 April 2013 (UTC)[reply]

Edit protect request to highly-visible template stalled?

Hi all! About a week ago, the Wikipedia:Route diagram template (RDT) project pushed out two edit requests to modify two highly-visible templates:

Template talk:BSpx; and
Template talk:BS-overlap.

However, it seems to me that these two requests were not addressed like other editrequests were, even after I wrote on WP:AN to ask to clear the backlog. May I know is there any special procedure to ask for large-scale modification to protected templates? Also can any administrator with the technical background to take a look on it? Thanks.

The background of this large-scale modification is at WT:RDT#Edit protected request 2013-04-17. — Peter why 16:42, 24 April 2013 (UTC)[reply]

Oh, I'm aware of it, just as I'm aware of all the other backlogged items at Category:Wikipedia protected edit requests, but I no longer touch anything that isn't 100% clear-cut cast-iron copper-bottomed uncontroversial; and in the case of templates (which these are) tested to destruction. This is because of the criticism that I have received when I fulfilled some requests that hadn't been discussed to death first. See also this discussion, if you have the patience. --Redrose64 (talk) 18:56, 24 April 2013 (UTC)[reply]

Hi Redrose, thank you for your response. I agree the original discussion has been quite limited to within WT:RDT, so I would like to know, what we should actually do to gain wider acceptance to this modification? And to eventually get the modification done? — Peter why 01:34, 25 April 2013 (UTC)[reply]

Admins unfamiliar with what a template does or how it works shouldn't carry out a proposed change without being certain that the change is beneficial, especially when the template is highly-visible. So, at the very least, I (and probably others) would like to see some WP:TESTCASES which both prove that these changes do what they're supposed to do, and also demonstrate that existing usage is not compromised.

I see that the proposed change to {{BSpx}} has been put into {{BSpx/sandbox}}, and that's great; but the proposed change to {{BS-overlap}} is not in {{BS-overlap/sandbox}}. Apparently it's in {{BS-overlap/sandbox2}} but that's more difficult to check since it doesn't have automatic links from the box at the bottom of Template:BS-overlap/doc nor from the {{editprotected}} box at Template talk:BS-overlap#Edit protected request 2013-04-19. The text after that states, rather vaguely, "we will have to modify some more unprotected templates afterwards" without detailing which ones nor in what way. I therefore cannot carry out any tests myself, which again means that testcases are needed.

As a frequent user of RDTs, I know what the overall suite is supposed to do, and for me there is one huge unanswered question: by changing the image size specifier from a height to a width, what will this do to those RDTs (such as this one) which use non-square icons? There are plenty of half-width icons such as (exdKHSTla); there are also some double-width icons such as

(bvWSL-BS2+lr) (and even a few quarter-width icons like

(cSTRq)); these have had a constant height because {{BSpx}} contains x20px and not 20px - testcases will go a long way toward showing that these still work. --Redrose64 (talk) 06:37, 25 April 2013 (UTC)[reply]

Template:BS-map

Yes, I see I have to address your concerns before getting things changed.

For location of sandbox of {{BS-overlap}}, that is in {{BS-overlap/sandbox2}}. The second sandbox was created by User:Sameboat before I started to work on this batch of modification, probably from a good intent to avoid erasing the previous content. If you know any way to merge the edit log of sandbox2 back to {{BS-overlap/sandbox}}, please do help to move that.
For complete front to end test cases, please find them inside WT:RDT#Proposed changes to protected BS-overlap, BSpx. We have made some maps that uses {{BS-overlap/sandbox2}} and {{BSpx/sandbox}}. If you would like to create some tests, use the sandbox directory to find the sandboxes we used for testing.
"we will have to modify some more unprotected templates afterwards": {{BSrow}}, {{BSrow-sc}}, {{BSrow-2}}, {{BSrow-replace}}, {{BSn}}, {{BSn-2}}, {{BSn-startCollapsible}}, {{BSn-replace}}. Again, these are the templates where sandboxes have been created to test for the new changes.
Double/half/quarter/3-quarter width: The transition should be smooth, except probably between {{BSpx}} and {{BS-overlap}} are updated and other templates (see above) are updated. Technically, we only move the x of x20px to {{BS-overlap/sandbox2}}. The aim is listed at WT:RDT#About PX parameter and Template:BSpx.

Let me know if you have any other concerns. — Peter why 13:53, 25 April 2013 (UTC)[reply]

Additional note for the last point: we did not change "the image specifier from a height to a width", we change that from size to height. So this does not conflict with the original intention to add that x to {{BSpx}}. — Peter why 15:16, 25 April 2013 (UTC)[reply]

Route maps 3x faster by {BS-overlap} update: Today, at 09:12, 28 April 2013‎, the route-map formatter Template:BS-overlap was updated (for the first time in 3 years) to use quick icon-overlay by {Template:Superimpose5} and omit {BS-alt} which was setting alt-text for each pictogram. Those changes have allowed many route-map diagrams to reformat about 3x faster, such as former 12-second maps now 4 sec. Unfortunately, the update also dropped the image-links (to each pictogram image-description page), which is likely improper handling of artwork-attribution links. Anyway, that update allows testing to confirm how the route diagrams can be edit-previewed 3x times faster now, and further updates can be discussed at WT:Route_diagram_template. Part of the problem had the fully-protected {BS-overlap}, and so there were several pent-up improvements which were delayed during the past 3 years. I have created a spike-solution variation to allow fuller testing of the complex features, and to format the pictogram alt-text much faster. However, the image-attribution links probably need to be re-added soon in Template:BS-overlap. -Wikid77 (talk) 10:25, 28 April 2013 (UTC)[reply]

Book deleter?

I've been using the book creator, & in the last week or so, I've had it wipe out my selections five times, for no apparent reason. If the page selection is interrupted, or the rendering is interrupted, it seems to reset & "lose" the rendering, & forces me to delete & add every page all over again. Last time, I left the rendering in progress overnight, & when I came back in the morning, the rendering was gone, & so was the list of pages. (Before that, at least the list survived.) The only connection I can find is my screensaver going on. Clearly, this system is buggy... TREKphiler ^{any time you're ready, Uhura} 22:30, 24 April 2013 (UTC)[reply]

Could you provide a specific example, and steps to reproduce for the problem? --AKlapper (WMF) (talk) 09:04, 25 April 2013 (UTC)[reply]

Colorized recent changes

I'm trying to interpret my user contributions page at Wikibooks. I can't find anything on the Wikibooks, Wikipedia, MediaWiki, or Meta projects, about this colorized recent changes scheme. The closest I got was some JavaScript mention...

Recent changes that are pending changes of history pages have a certain color to that item on the list. OK. Does the color have a general meaning as regards recent changes? Wikibooks user contributions pages have a color scheme that has the "pending" color, and it has other colors. — Cpiral Cpiral 01:20, 25 April 2013 (UTC)[reply]

Wikibooks has customized the recent changes to have tag markers coloured in pink. Is this what you mean, or are you referring to some other colour? This is a customization that the wikibooks folks did themselves, and is not a default part of the software. These tags are added by the abuse filter to mark edits which meet certain patterns. See Wikipedia:Tags for info on revision tagging. Bawolff (talk) 16:20, 25 April 2013 (UTC)[reply]

Wikibooks b:Special:Contributions/Cpiral reports green and tan today. (The tan looked to be near the color as mw:Special:PendingChanges when I first saw it.)

You said the colors are indicated in custom CSS, and I say "those criteria" that colorize the contributed items are not user-documented in such a way that an experienced editor can search to find within a reasonable amt of time. Is it possible to conclude here that Wikipedias Help:User contributions is missing a mention? It would be if there was an agreement of colors at meta. (As you say, such an agreement is surely not a concern of MediaWiki.) If there is not an agreement at meta, then Wikibooks needs to import our page, and update it with the color scheme. Its just wrong to give a requested report without an explanation of what it means. This is just a question of what work we might agree needs to be done to remedy that glaring omission. — Cpiral Cpiral 16:35, 26 April 2013 (UTC) — Cpiral Cpiral 18:28, 27 April 2013 (UTC)[reply]

broken template

Could someone please fix {{repetition-inline}}; there is a trailing pipe "%7c" breaking the link. I couldn't fix it myself. Thanks. Fgnievinski (talk) 07:40, 25 April 2013 (UTC)[reply]

I've made an edit, though there may well be a better target for the "link" parameter. -- John of Reading (talk) 08:06, 25 April 2013 (UTC)[reply]

Relinking Google for SSL https

There are still articles linked in Google with secure-server SSL prefix "https:" (rather than "http:"), and the pageviews in stats.grok.se have been down to 75% lower for some of those pages. To unlink and relink article "Parabola" now I have, step 1, renamed it as typical "Parabola (mathematics)" (which Google has indexed with "http:" prefix), while "Parabola" remains a redirect. The plan is to rename "Parabola (mathematics)" back again, and see if that resets and relinks the original title "Parabola" as simple http protocol. Then we can check the pageviews to see if they rise back near 2,500 pageviews/day from the recent 600/day. Questions:

Should we wait a whole week before renaming back to "Parabola" to relink?
What has caused some articles to relink as secure https in Google?
Even if relinked as http protocol, will Google later return to https links?

If we can get confirmation, where "Parabola" can be relinked and return to nearly 4x times higher pageviews, then I would conclude that Google's secure-server https links are hindering users from reading pages. Meanwhile, I am considering to rename back within a few hours, unless someone knows it typically takes several days to reset an https link in Google. -Wikid77 (talk) 11:05, 25 April 2013 (UTC)[reply]

What the... ? I've undone this move (which broke the hatnote, by the way): we do not randomly move pages around based on our own personal theories as to how Google works, and I can't even comprehend the problem statement. If you want to experiment, you've got a sandbox to do so. Chris Cunningham (user:thumperward) (talk) 12:20, 25 April 2013 (UTC)[reply]

Other editors have been discussing Google's https article-links for some weeks now, but it is a very complex problem which will be difficult for many people to comprehend without weeks of study. Fortunately, this is a wiki, and there are other people to help handle complex issues. -Wikid77 13:22, 25 April 2013 (UTC)[reply]

Double-renaming did not relink article as http protocol: After a period of 2 hours, the article was re-renamed from new http-protocol title "Parabola (mathematics)" back to "Parabola" but that did not immediately reset the Google https link as being http protocol, as would be expected if the old name were deleted, then the rename performed later. -Wikid77 13:22, 25 April 2013 (UTC)[reply]

- File a bugreport in bugzilla with wmf site-requests. They have some contacts in Google. Will probably take long, but it can help. I doubt however that it really does matter a lot in traffic if Google found it primarily by https or by http. I wonder however if perhaps there is an issue with non-canonical duplicates of this page somewhere, which might affect it's page rank. If there are canonical issues, then that could also explain why google becomes confused and moves it to https as primary protocol. —TheDJ (talk • contribs) 14:02, 25 April 2013 (UTC)[reply]

I would be interested in knowing why we think (or more specificly how it happens) that google pointing people to https has a negative correlation with page views? Bawolff (talk) 16:31, 25 April 2013 (UTC)[reply]

Several major articles with Google https links have lower pageviews: There is very strong evidence of articles with Google https links having relatively low pageviews in April 2013:

Page https "Parabola" (stats-201304, 600/day formerly 2,500/day) lower than rare "Hyperbola" (stats-201304 1,300/day)
Page https "Gone with the Wind (film)" (stats-201304, 1,860/day formerly 4,900/day) lower than "Lawrence of Arabia (film)" (stats-201304 2,800/day)

Because the term "parabola" is 5x more common in Google hits, the pageviews should be higher, not 50% lower, than for the rare term "hyperbola". Similarly, the article "Gone with the Wind (film)" (as an American cultural icon from 1939) should have higher pageviews than "Lawrence of Arabia (film)" (1962), rather than 33% lower. In general, highly popular articles should have much higher pageviews, compared to similar but less-popular topics. The renaming of page "Parabola" as "Parabola (mathematics)" was intended to delink "Parabola" in Google, to allow deletion of the redirect, and then re-renaming back to "Parabola". However, the deletion might have required a multi-day period with no redirect named "parabola" (as wp:SALTed to prevent re-creation), and that would likely have caused more debates. All of this is compounded by re-indexing a page in Google without revealing the complex trade secrets of how Google's PageRank algorithm operates. Hence, the re-indexing of https-link pages in Google might be better if handled as a discrete wp:OFFICE action, without a lot of public discussion about Google's company-proprietary PageRank methods. -Wikid77 (talk) 03:50, 27 April 2013 (UTC)[reply]

the article "Gone with the Wind (film)" (as an American cultural icon from 1939) should have higher pageviews than "Lawrence of Arabia (film)" (1962), rather than 33% lower. Sorry man, but that's completely bogus. — Scott • talk 12:26, 27 April 2013 (UTC)[reply]

Weird...

Was updating the centiJimbo userbox and stumbled on this in Jimbo's userpage history. The "older" edit was indeed to the userpage [2], but 2 years later. Any clue what's up with it? Just a weird ghost in the machine from all the software transitions back then? Screwed-up histmerge? — PinkAmpers &^{(Je vous invite à me parler)} 12:02, 25 April 2013 (UTC)[reply]

A known side effect of history merging. —TheDJ (talk • contribs) 13:50, 25 April 2013 (UTC)[reply]

General MediaWiki database corruption from 2004: There are other pages which show corrupted revision links from 2004. In this case, with page "User:Jimbo_Wales" the original entries were from January 2002, but it seems 81 of those oldid numbers, in range 7476700-7476782, were reassigned to later transactions of edits made during September/November 2004, which should have been higher id numbers. Compare some of those revisions around id=7476700:

dif670 dif680 dif690 dif700 dif710 dif720 dif730 dif740
dif750 dif760 dif770 dif780 dif784 dif790 dif800 dif800 dif800

I guess someone could hand-update those database records, to have the correct next/previous oldid links, but there are over 110 bad links in those database id numbers already. -Wikid77 (talk) 14:55, 25 April 2013 (UTC)[reply]

@TheDJ, it's not a side effect of history merging anymore, but it was before MediaWiki 1.5 was released in 2005 (see my musings on the subject). The history merge that ddid this appears to be this one; see the relevant deletion log (warning: ginormous page!) and search for the username "Fennec" without the quotes. Graham87 08:16, 26 April 2013 (UTC)[reply]

User talk pages not loading with Firefox

Tracked in Phabricator
Task T49457

I can't get user talk pages to load today using Firefox. Other pages are fine, but user talk pages won't load as diffs or when I try to edit them. It's only happening with Firefox. SlimVirgin ^(talk) 21:21, 25 April 2013 (UTC)[reply]

Amusingly this is happening to me with user pages and some diffs. It has improved a bit during the day but not that much. Now it takes me a few tries. Snowolf ^{How can I help?} 21:23, 25 April 2013 (UTC)[reply]

There are a few threads about this up above from yesterday; try disabling the WikiLove tab (in Special:Preferences, on the "Misc." tab) and see if that helps. Writ Keeper ⚇♔ 21:24, 25 April 2013 (UTC)[reply]

I started seeing this too today. In Firebug Net tab, it says these URLs are loading endlessly:

http://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-HotCat.js&action=raw&ctype=text/javascript

http://en.wikipedia.org/w/index.php?action=raw&ctype=text/css&title=MediaWiki:Gadget-navpop.css

http://en.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=MediaWiki:Gadget-popups.js

If I interrupt loading quickly enough, it doesn't get stuck like that and I see the page normally. Really annoying, though. --Joy [shallot] (talk) 21:51, 25 April 2013 (UTC)[reply]

I disabled WikiLove as Writ Keeper suggested, and the talk pages loaded again. I re-enabled it, and then they wouldn't load. So that seems to be the culprit. Thanks, WK. SlimVirgin ^(talk) 21:57, 25 April 2013 (UTC)[reply]

In the meantime I found bug 47457 (esp. comment #28). Ditto. --Joy [shallot] (talk) 22:15, 25 April 2013 (UTC)[reply]

This is handled in bugzilla:47457 and being worked on. Sorry for the inconvenience. Also see "Temporarily disabling WikiLove on English Wikipedia" below. --AKlapper (WMF) (talk) 10:03, 29 April 2013 (UTC)[reply]

Test the new login and account creation page designs

Hi all,

After many weeks of testing, We (the editor engagement experiments team) are is getting close to enabling redesigns of the account creation and login pages. (There's more background about how we got here and why ‎our blog post.)

Right now are trying to identify any final bugs before we enable new defaults. This is where we really need your help: for now, we don't want to disrupt these critical functions if there are outstanding bugs or mistranslated interface messages. So for about a week, the new designs are opt-in only for testing purposes, and it would be wonderful if you could give them a try. Here's how:

Go to account creation and add &useNew=1 to the URL, or just use this link
Go to login and add &useNew=1 to the URL, or just use this link

If you have questions about how to test this or why something might be the way it is, I'd definitely check out our step-by-step testing guide and the general documentation.

Many thanks, Steven Walling (WMF) • talk 22:39, 25 April 2013 (UTC)[reply]

Will Special:PasswordReset be updated to reflect this new design as well? —Theopolisme (talk) 01:38, 26 April 2013 (UTC)[reply]

No, though if you think it should be, it should be simple enough. Steven Walling (WMF) • talk 04:59, 26 April 2013 (UTC)[reply]

I've taken the liberty of making the test links protocol-relative (i.e. they go to the HTTPS site if the user is on the secure server, otherwise they go to the HTTP site). Graham87 06:29, 26 April 2013 (UTC)[reply]

Thanks Graham. One of the nicer parts of the new login form IMO is that it includes a default link to the HTTPS connection, if you're not already on it. Steven Walling (WMF) • talk 06:32, 26 April 2013 (UTC)[reply]

The gray text used for the form field labels (e.g. "Username", "Password") is too light: it is difficult to read, and moreover, it is not compliant with WCAG accessibility guidelines. Please consider darkening the text colour a bit. — This, that and the other (talk) 06:41, 26 April 2013 (UTC)[reply]

Agree. How many times has this happened before ? Don't the designers have this on their checklist by now ? —TheDJ (talk • contribs) 10:29, 26 April 2013 (UTC)[reply]

The lighter color is very much intentional, and in several rounds of usability tests (here's a few who gave us permission to share), we've seen pretty much all users be able to read fields contents with this color. It's explanatory content, and is thus lower priority than the actual field titles. Making all text the same style reduces usability for the majority of users. Steven Walling (WMF) • talk 20:43, 26 April 2013 (UTC)[reply]

I don't object to using gray text, I think it looks good, but aren't you bothered by the rather low contrast level in terms of accessibility? It is absolutely crucial that our login form is as accessible to as many people as possible. — This, that and the other (talk) 01:02, 27 April 2013 (UTC)[reply]

And how many people in that group of testers had a severe form of colorblindness ? Just because nobody in the testgroup complains about the lack of a level floor in a new building doesn't mean much until you bring someone with a wheelchair. I don't blame people for NOT taking this into account when testing. I didn't even notice myself until TtatO brought it up and usually i'm one of the first to complain about these issues. There are WCAG checklists for a reason, namely the fact that many of those points are hard to notice for people that don't have disabilities. That's why you build a checklist. Not to cross off every point like a machine, but to make your mind actively consider the step (Ask airline pilots). —TheDJ (talk • contribs) 08:06, 27 April 2013 (UTC)[reply]

In general, like. I thought you guys were adding inline validation as well btw ? Or is that for a later phase ? If you take away the security advise etc from the interface, and don't give people tooltip advise, I'm sure some ppl will start wanting the headers with advice back. Also, slightly related: How about changing the "email (optional)" into "email (advisable/recommended)" ? —TheDJ (talk • contribs) 10:26, 26 April 2013 (UTC)[reply]

Also, AFAICS, there is no opportunity to add extra footer text: see [3] and [4]. Obviously it looks a lot better without footer text, but sometimes there may be a need for the community to add various timely messages to this part of the screen. — This, that and the other (talk) 10:41, 26 April 2013 (UTC)[reply]

I agree with "Email (recommended)" over (optional) as that would encourage people to provide their email address and they'd be able to get all the future benefits of Echo, Flow etc. Thehelpfulone 16:20, 26 April 2013 (UTC)[reply]

TheDJ: yeah, we deferred inline validation until another release. We'll either refactor using the validation HTMLForm already provides, or rebuild the backend of the form on top of the API (which supports CAPTCHA delivery now, thanks to Brion). Regarding the email label: remember that most users don't expect email to be optional, it's actually kind of unusual compared to the other popular sites on the Web. If we want to recommend email strongly, we could consider doing something like adding a suggestion to provide it, if people skip the field before submitting (this would require client-side validation, of course). An interim compromise could be "(Optional, but recommended)" which is clear but slightly wordy. Thoughts? Steven Walling (WMF) • talk 21:00, 26 April 2013 (UTC)[reply]

Temporarily disabling WikiLove on English Wikipedia

Per Template:Bug and the discussion above, I'm going to temporarily disable the WikiLove extension until the underlying issues with mw.loader are resolved. Sorry for the inconvenience. If you need to spread WikiLove in the meantime, please reacquaint yourself with Category:WikiLove templates :) Kaldari (talk) 00:34, 26 April 2013 (UTC)[reply]

Ha. Questionable timing, Kaldari--it's Friday, and who isn't in the mood for love on a Friday? I was just about to give it up to Wizardman. Drmies (talk) 17:43, 26 April 2013 (UTC)[reply]
- Hopefully the WikiLove crisis will be over soon: https://gerrit.wikimedia.org/r/#/c/61057/ Kaldari (talk) 00:07, 27 April 2013 (UTC)[reply]
  - What do ya know. I haven't used WikiLove in ages. I was going to use it tonight, but I guess Wikipedia isn't feeling the love. MJ94 (talk) 01:38, 28 April 2013 (UTC)[reply]

Transliteration in searching

Hello, the search engine doesn't know to associate characters with their diacritics. For example if your search word has an "a", it won't suggest the same word that contains "á" instead of "a".

On Romanian Wikipedia, when I search for Carol Popp de Szatmary it shows only 3 results, and it won't include the ro:Carol Popp de Szathmári article, which is almost the same with the text I was searching. You can check that for yourself: [5] or search Szatmary

Another example: search for „Agri” and the result doesn't include ro:Ağrı.

I already reported the bug here: Help talk:Searching#Transliteration in searching - Help talk:Searching/Archive 4#Transliteration in searching. If the auto-suggest drop-down list doesn't know to make those associations - fine (even though 2013 sounds like a lot). But the search engine should definitely know how to make such associations, in my opinion. Thanks. — Ark25 (talk) 06:04, 26 April 2013 (UTC)[reply]

Well, I made an error, I haven't noticed the extra "h" in the "Szathmári" word. However, the "Ağrı" example is valid. I think the search engine should associate "ğ" with "g". — Ark25 (talk) 08:32, 26 April 2013 (UTC)[reply]

As far as I can tell, the problem character in your other example is not ğ but ı (lower case dotless I). A search on agrı does find ro:Ağrı, but it doesn't find ro:Agri. The character is treated oddly. If it's the first character in a wikilink then it automatically works as i, for example in ı or ıce. If it's not the first character then it makes a redlink, for example kıte. If you enter ı in the search box and there is a title match with i instead of ı then it goes there, for example "kıte" goes to kite (with no redirect). But a search on kıte finds nothing. ı and i appear identical to the "Go" feature of the search box, but they aren't associated at all in searches. PrimeHunter (talk) 10:26, 26 April 2013 (UTC)[reply]

You are right. Also it jumps directly if ı it's the last character: typing in the searchbox "Ağri" and pressing enter - will jump directly to Ağrı, just like in the ıce case (and I think it should not jump there, it should just show the article on the top of the search result list). But if you search for "Ağri" the Ağrı article will not show in the search result list. — Ark25 (talk) 10:43, 26 April 2013 (UTC)[reply]

That ıce = Ice = ice is undoubtedly due to the fact that the uppercase mapping of ı, as defined in the Unicode standard, is I.[6]—Emil J. 11:43, 26 April 2013 (UTC)[reply]

In fact, this probably also explains why “kıte” goes to kite from the search box: the “Go” feature appears to fold all letters to uppercase before attempting a match—if you type in “kItE”, it also goes to the same article.—Emil J. 11:54, 26 April 2013 (UTC)[reply]

Ah yes, {{uc:ı}} returns I, the normal upper case letter. This means that {{lc:{{uc:ı}}}} returns i, the normal lower case letter and not the one you started with. bugzilla:33643 is related. I don't know whether there is a bugzilla entry for i and ı not being associated in searches. PrimeHunter (talk) 13:23, 26 April 2013 (UTC)[reply]

Technical editors

Dear tech people:

Does Wikipedia have volunteer technical editors (for creating the scripts, tools, templates, etc.)? If so, where is the best place to inquire about becoming one of them? I have substantial, although somewhat outdated, experience in this area. —Anne Delong (talk) 14:45, 26 April 2013 (UTC)[reply]

What do you need? mabdul 16:10, 26 April 2013 (UTC)[reply]

I don't need anything in particular right now myself, I just enjoy coding, and wondered if this was a way I could help. If that's not allowed, just say so. — Preceding unsigned comment added by Anne Delong (talk • contribs) 19:47, 26 April 2013 (UTC)[reply]

Yes, there are ways for volunteer coders to contribute. The easiest (least sophisticated) way is through writing templates, which are just bits of specialized wikitext in the Template namespace. We also have Gadgets (written in Javascript), Modules (written in Lua), Skins (written with CSS). For more sophisticated programmers, one can also volunteer as a Mediawiki hacker (using PHP). With a bit more guidance about what you are looking for, perhaps we can point you in a more specific direction. Dragons flight (talk) 19:59, 26 April 2013 (UTC)[reply]

If you are able to edit the required page then you can just go ahead. Creating and editing templates, Lua modules or user scripts is like editing articles. There is no application process or official teams or leaders assigning tasks. PrimeHunter (talk) 23:17, 26 April 2013 (UTC)[reply]

Watchlisting this page would be a good start. People come here a lot to seek help from people such as yourself. Also, #mediawiki ^connect and #wikimedia-tech ^connect have lots of your types. :) Killiondude (talk) 01:08, 27 April 2013 (UTC)[reply]

Thank you. I would like to help out, but I know that errors can have more serious repercussions than when editing a regular text page. Are there standards and procedures essays that I should read before I make any changes? Or is everything usually located on the talk pages attached to the object? I am familiar with Javascript and PHP, but I would rather start out small. —Anne Delong (talk) 14:44, 27 April 2013 (UTC)[reply]

Section title "AD" disappears

I type:

Above section header
===AD===
Below section header

And I see rendered:

Above section header

AD

Below section header

AD is the prefix of some old vacuum tubes. I can't jump there from the table of contents, either. I had to insert a blank between A and D as a workaround.

Is that some misguided spam filter? --Mkratz (talk) 16:27, 26 April 2013 (UTC)[reply]

Oh, I just found out. It's the AdBlock Plus extension in Firefox. Lots of people have that installed. Now what? --Mkratz (talk) 16:40, 26 April 2013 (UTC)[reply]

I don't have any problems seeing it with AdBlock enabled (though I usually have it disabled on en.wikipedia.org). It will surely depend on which filters you use in AdBlock. — HHHIPPO 17:21, 26 April 2013 (UTC)[reply]

Right. Seems I've neglected to choose the filter, so AdBlock defaulted to FanBoy's. No problems anymore with EasyList.

Yet, I guess I better leave the workaround in place. --Mkratz (talk) 18:14, 26 April 2013 (UTC)[reply]

Indeed, FanBoy's filter is blocking the word "ad". I wonder if that makes sense. How about this workaround: ===AD === ? That looks basically the same, but tricks the filter. — HHHIPPO 20:51, 26 April 2013 (UTC)[reply]

Is FanBoy contactable? Could he be asked to correct his filters to not cause the false match? – PartTimeGnome (talk | contribs) 21:07, 26 April 2013 (UTC)[reply]

Might trick FanBoy, but there are lots of others. Better steer clear from the treshold. --Mkratz (talk) 22:18, 26 April 2013 (UTC)[reply]

Anyone willing and able to fix User:GregU/dashes.js?

User:GregU seems to have become inactive, and I've discovered a bug in this widely-used script (it has been incorporated in AutoEd, and is a js gadget).

The bug is pretty simple: it will modify the dashes and hyphens in section headers, and this breaks any wikilinks from redirects or other articles that link directly to the section. All it takes to fix it is to place {{anchor|original section header}} as the first line in the modified header whenever the tool modifies a section header. That way, people that worry about the appearance of dashes vs. hyphens stay satisfied and the incoming wikilinks and redirects stay working.

Anyone comfortable enough with Javascript editing of Wikipedia articles to take on the fix?—Kww(talk) 22:40, 26 April 2013 (UTC)[reply]

/me points to User:Writ Keeper. —Theopolisme (talk) 22:57, 26 April 2013 (UTC)[reply]

How about first asking the right question? We need to find out whether anybody has witnessed the breaking of such a link, or potentially how many articles the alleged "problem" would affect? -- Ohconfucius ^{ping / poke} 01:41, 27 April 2013 (UTC)[reply]
There are some other glitches that have already manifest as actual errors, as notified on the owner's talk page. -- Ohconfucius ^{ping / poke} 02:39, 27 April 2013 (UTC)[reply]
- Storm in a teacup, if you ask me, Kww. Tony (talk) 10:22, 27 April 2013 (UTC)[reply]

No one in the real world cares to force hyphens as dashes: Every so often we need people to come up for air, and learn that the world has stopped caring about the hyphen/dash issues. However, months ago someone had misled me into thinking the prestigious journal Nature had somehow advocated a style to use dashes between two-term expressions; however, after days of closer inspection, I discovered the truth is that Nature allowed the authors to use whichever dash/hyphen styles they preferred, even to mix hyphens and dashes in conflicting styles, such as page ranges "2-5" and "2–6" in the same peer-reviewed article. The 19th-century term "hyphenated Americans" states exactly what punctuation to use. Also, I learned, with the Michelson-Morley Experiment, even those two scientists spelled their Experiment with a hyphen (not a dash). Perhaps more confusing, the Adobe Reader will search with hyphen to match any dash or hyphen in the PDF-format text. Changing hyphens to dashes is just not as important as imagined some years ago, and has become viewed as balderdash. The world decided it did not care, and even hyphens have been removed from formerly hyphenated terms during the past 40 years. Spread the word down to the wiki-mines underground. -Wikid77 (talk) 22:17, 28 April 2013 (UTC)[reply]

Skin issues

I'm trying to replicate the appearance of the Classic skin within Vector, and would appreciate some guidance in customizing my (already-heavily-modified) css and js files. I was getting some help on meta:Tech, but that seems to have dried up for now. Note that I didn't write these modifications; other people very generously wrote them for me. Current issues include:

I'd like a "my contributions" link on all pages.
I'd like a "Watchlist" link on all pages.
I'd like a "current version" link on pages where I compare two diffs.
I'd like the "new messages" notifier to be at the very top of the page, rather than at the top of the article. Note that I already have modifications to remove the orange bar, because the orange bar is hideously ugly.
The vertical separator bar is an ugly shade of light blue. I'd like it to be a pleasant gray (RGB: 128, 128, 128). I know how to change most of the font colors already (and am actively doing it because the colors that Vector uses are ugly), but not the separator bar colors.
On a related point, the vertical separator bar goes too far down. It should stop just past the first four lines of the article (or equivalent). And no horizontal separator bar at the very bottom of the page, thank you.
The relative font sizes of the various elements are wrong. Currently, the font size of article text is (X), but the font size of text in the edit window is (Y). I would like these to be inverted. I would also like the text in the sidebar to be (X) rather than (Y).
I would like the sidebar to be somewhat narrower - like how it was in Classic.
I would like to completely eliminate all use of the "star" icon as it pertains to the "watch page" function.
There's an unsightly empty space at the top of the page (see File:Classic vs heavily-modified Vector (skin comparison) 1.jpg, File:Classic vs heavily-modified Vector (skin comparison) 2.jpg, and File:Classic vs heavily-modified Vector (skin comparison) 3.jpg -- but it's present in unmodified Vector too, just smaller). I'd like it refilled with the links shown in the comparison jpgs.

Thank you in advance for any advice or suggestions you can provide. DS (talk) 02:23, 27 April 2013 (UTC)[reply]

How can a page exist without any history

The page MediaWiki:Common.css/User:Paladox2014 exists (in that it's got an "edit this page" link not a "create this page" link), but it has no history. How can that happen? --Redrose64 (talk) 19:44, 27 April 2013 (UTC)[reply]

The same thing happens for all subpages of MediaWiki:Common.css. Assuming it's just a placeholder built into mediawiki. —Theopolisme (talk) 19:49, 27 April 2013 (UTC)[reply]

"MediaWiki:Common.css/User:Paladox2014" means the interface message "common.css" in the language with code "User:Paladox2014", just as "MediaWiki:Common.css/de" means the interface message "common.css" in German (code "de", from ISO 639). Of course, no language has code "User:Paladox2014", so it falls back to the default English message distributed with MediaWiki.

Since the interface message "common.css" does exist in MediaWiki, the software displays an edit link rather than a create page link. Anomie ⚔ 21:43, 27 April 2013 (UTC)[reply]

As a little curio, non-existing languages cannot be chosen in preferences, but they can actually be chosen with uselang= in the url. For example, the page MediaWiki:Uploadtext/en-screenshot exists although "en-screenshot" is not intended as a language code. But if you replace http://en.wikipedia.org/wiki/Special:Upload with http://en.wikipedia.org/wiki/Special:Upload?uselang=en-screenshot then the software thinks you want to display Special:Upload in a language called en-screenshot, so you see MediaWiki:Uploadtext/en-screenshot. PrimeHunter (talk) 21:59, 27 April 2013 (UTC)[reply]

OK. Does anybody know why on earth Paladox2014 (talk · contribs) might need to create that page (see MediaWiki talk:Common.css/User:Paladox2014), or indeed what they're up to? The user account was created only yesterday, but from their edits so far (the very first was to create MediaWiki talk:Common.css/Wikipedia:Main Page/sandbox), I get the distinct impression that they want to jump right in with something hideously complicated - a redesign of the main page (without discussing it with others) is just one possibility. I might have formed entirely the wrong impression though. --Redrose64 (talk) 22:59, 27 April 2013 (UTC)[reply]

At the page you linked above, xe said "but how can I create for example Mediawiki:Common.css/User:Paladox2014/Main Page"...which makes it look like this was a failed attempt at that. WP:CLUE could be an issue. —Theopolisme (talk) 23:07, 27 April 2013 (UTC)[reply]

Removing the "Secure your account" information from the login screen

Hi. I've started a discussion at MediaWiki talk:Loginend#Future of this message about whether we want to continue including the "Secure your account" information on the login screen. Please discuss at the link provided. --MZMcBride (talk) 21:43, 27 April 2013 (UTC)[reply]

<Imagemap>

I recently created a clickable image for the infobox in Paris using Extension:ImageMap. However, this has added a couple of extra lines around the image, so is there a way for the infobox to look like it does in this revision but still to be clickable?--Gilderien Chat|List of good deeds 22:17, 27 April 2013 (UTC)[reply]

Done.[7] PrimeHunter (talk) 22:33, 27 April 2013 (UTC)[reply]

Thank you very much :) --Gilderien Chat|List of good deeds 22:38, 27 April 2013 (UTC)[reply]

Please say yes or no to this Afc proposal.

Dear editors: Last week I posted a proposal for an addition to the Afc submission process at my user page User:Anne Delong/AfcBox and asked the reviewers on the Afc talk page to respond at User talk:Anne Delong/AfcBox. After several of the reviewers showed interest, and with support from FoCuSandLeArN and some input from mabdul I asked for a technical assessment at Wikipedia:Village pump (proposals) and also at Village pump (technical).

Since then there has been a lot of discussion on all three talk pages about various ways to improve the Afc submission process, but aside from TheDJ, who indicated that my proposal was technically feasible, and Ypnypn , who agreed that PHP shouldn't be needed, all of the discussion has centred around alternative and more complicated ideas using bots, javascript, etc. These are likely good ideas, but don't provide feedback on my original simpler proposal.

Please will someone let me know if this simple proposal (rather than the other alternative ideas) is worth pursuing, or what's wrong with it if not, by posting your opinions at User talk:Anne Delong/AfcBox. If no one likes the idea, and people instead want to go in a different direction, I will delete it. If people agree that the proposal has merit. Petrb has agreed to set it up. I am posting this on all three talk pages hoping to get a decision one way or the other. Thanks for your time. —Anne Delong (talk) 22:56, 27 April 2013 (UTC)[reply]

Does anyone have a list of retired namespaces?

Due to the nature of this question, I believe that this is the correct forum for it. As an editor who did not become really involved in Wikipedia until 2012, but did look at Wikipedia from time to time from 2004 and onward, I thought I remembered seeing other name spaces on Wikipedia than the ones that exist today such as (article), Wikipedia:, Help:, MediaWiki:, Template:, etc. Essentially, I'm trying to build a proposal for a new namespace, but I want/need to make sure that what I'm trying to propose doesn't take the Wikipedia project backwards in time. So, does anyone have a list of any retired namespaces, or could someone either direct me to a page in Wikipedia where this list can be found? Steel1943 (talk) 23:57, 27 April 2013 (UTC)[reply]

Wikipedia:Namespace lists all of them, if I'm not mistaken. What exactly are you trying to propose? —Theopolisme (talk) 00:19, 28 April 2013 (UTC)[reply]

Thanks for that link Theopolisme, but that article only lists currently active namespaces; I'm looking for retired ones. And for your second question: basically, look at my user page for the answer to that one: I'm not trying to bring too much attention to that proposal since I have no idea yet if I would be taking steps backwards in the progress of this Wikipedia. Knowing about any retired name spaces could help with my latter concern. Steel1943 (talk) 00:42, 28 April 2013 (UTC)[reply]

An aside: I don't think that "stepping backwards" is always a bad thing. But in looking at your proposal and doing a bit of searching, I don't think that a specific Draft space has ever existed on Wikipedia. —Theopolisme (talk) 01:14, 28 April 2013 (UTC)[reply]

I am pretty confident that no namespaces have ever been "retired". — This, that and the other (talk) 01:53, 28 April 2013 (UTC)[reply]

indeed, no namespaces have ever been discontinued here. Graham87 04:49, 28 April 2013 (UTC)[reply]

We have switched the default names for certain namespaces ("image" has mostly been switched to "file"), but the same namespace still exists (and the old names\links still work). Could this be what you're thinking of? Andrew Gray (talk) 22:45, 28 April 2013 (UTC)[reply]

TorBlock problems

Tracked in Phabricator
Task T49626

It's been the third time this week I've received an unblock request on WP:UTRS from an established user who was running a Tor node which was not an exit node, but merely a relay node, and it was blocked by mw:Extension:TorBlock. This appears to be a systematic problem. I've filed a bugzilla request, but it hasn't yet been addressed. What should we do in the meantime? -- King of ♥ ♦ ♣ ♠ 02:53, 28 April 2013 (UTC)[reply]

Thanks for filing the bug report! It was filed four days ago and there was a weekend in-between, so I'd be a bit more patient. Andrew Garrett is CC'ed on the bug report, and as far as I know he'd be a good person to contact about it. --AKlapper (WMF) (talk) 10:06, 29 April 2013 (UTC)[reply]

Updating portal box images

I am looking to update the image displayed for the Portal:Coffee portal box (the box that's used in the See also sections of articles). I know that there's a page to update the image, but I just cannot find it at this time. I'm looking to update the generic portal puzzle image with File:A small cup of coffee.JPG. Northamerica1000^(talk) 03:17, 28 April 2013 (UTC)[reply]

See Template:Portal#Image Nanonic (talk) 04:20, 28 April 2013 (UTC)[reply]

Resolved. Thanks very much Nanonic. Cheers, Northamerica1000^(talk) 05:07, 28 April 2013 (UTC)[reply]

Cat Scan

Is there a way i can find the articles of a category in english wikipedia that have an article in italian wikipedia? Xaris333 (talk) 11:47, 28 April 2013 (UTC)[reply]

Sounds like something you might want to ask the Wikidata folks. —Theopolisme (talk) 12:45, 28 April 2013 (UTC)[reply]

Done! Xaris333 (talk) 01:03, 30 April 2013 (UTC)[reply]

Wrong version of Edit tools

Resolved

Hi. Two or three days ago, the version of the Edit Tools that I get changed from the click-to-insert version depicted at MediaWiki:Edittools to the much more clunky copy-to-paste version. I haven't touched my preferences (and can't even see which preference would affect this). MSIE8 with active scripting enabled; Vector skin. Thanks for any help. --Stfg (talk) 13:21, 28 April 2013 (UTC)[reply]

Sounds like js in general might be failing somewhere - do other things still work, such as the search dropdown options, collapsible navigation, etc? -— Isarra ༆ 17:25, 28 April 2013 (UTC)[reply]

(edit conflict) what you describe is not what editTools supposed to do, and it's not what it does for me, so i think the problem is not general, but somehow specific to you. the first thing i'd do is try to see if it's related to your browser/computer or to your user account. the simplest way to test it is to log out, and try it again: edittools is on by default (too lazy to check, but i think it's a default gadget, rather than something added by Mediawiki:common.js ). if it has to do with your account, you probably want to go over your vector.js and common.js, and comment out one line at a time until you find the culprit, and discuss it with the owner of the imported script. if it happens when logged out also, please come back here and report - with as many details as you can (browser precise version, OS, which edittool is it that behaves this way, maybe even in which article did it happen, and any other detail you can think of). peace - קיפודנחש (aka kipod) (talk) 17:27, 28 April 2013 (UTC)[reply]

Search dropdown and collapsible navboxes work fine. Problem goes away when I log out. I've completely cleared my vector.js, common.js and, for good measure, vecrtor.css also (and remembered to clear the cache

) None of this removes the problem when logged in. By the way, I get the desired click-to-insert edit tool when editing these three files -- but only these three; editing anything else -- mainspace article, page in my user space, template -- still has the problem. I haven't done anything to my account for ages. I have Win XP (home) with SP3, fully patched. Browser version is MSIE 8.0.6001.18702. Thanks again for looking at this. --Stfg (talk) 19:26, 28 April 2013 (UTC)[reply]

I've bypassed the problem by removing one of the scripts from my vector.js and have started a discussion with the designer. Please don't invest any more of your time in it, and thanks for the help so far. --Stfg (talk) 16:36, 29 April 2013 (UTC)[reply]

Range viewing with IPv6

I use the CIDR range notation tool sometimes when viewing IP editing history (so I can find /24 addresses, for instance)... is there a similar tool for IPv6 addresses? Or is there a way to make it work with IPv6? Shadowjams (talk) 14:37, 28 April 2013 (UTC)[reply]

Manipulating categories

Resolved

Is there a way (a Special page similar to Special:ComparePages, perhaps) to see an automatically generated list of all the members of e.g. $\left(CategoryA\lor CategoryB\right)$ , $\left[\left(CategoryA\land CategoryB\right)\lor \left(CategoryC\land \neg CategoryD\right)\right]$ , etc.? It Is Me Here ^{t / c} 15:03, 28 April 2013 (UTC)[reply]

Yep, Wikipedia:CatScan seems like exactly what you're looking for. —Theopolisme (talk) 15:08, 28 April 2013 (UTC)[reply]

Thank you It Is Me Here ^{t / c} 09:27, 29 April 2013 (UTC)[reply]

Parser function question

I notice that the #if: function would trim line breaks from parameters 2 and 3, as shown above with User:Peterwhy/sandbox. I would like to know if this is an intended effect? Thanks. — Peter why 18:37, 28 April 2013 (UTC)[reply]

It's a known and long-established feature of the MediaWiki template parser that leading and trailing whitespace is significant around positional parameters, but not around named parameters. It's unlikely to change. Parser functions such as {{#if:}} strip surrounding whitespace from their output. --Redrose64 (talk) 20:04, 28 April 2013 (UTC)[reply]

Use the space-sensitive if-templates: There are some special templates which allow a space-sensitive result, with newline linebreaks, in conditional expressions. For example, using Template:ifeq or Template:ifexpr:

"{{ifeq|{{{it|xx}}}|xx| It is xx. }}" → " It is xx. "
"{{ifexpr|{{{| {{{age|19}}} >= 18}}} | Over 18 }}" → "Template:Ifexpr"

Those templates are extremely fast, so could be used hundreds of times with no significant delay. When the data contains an equals sign ("="), then pass the data inside a null-named parameter {{{|____}}}. -Wikid77 (talk) 23:05, 28 April 2013 (UTC)[reply]

Wikid77, please stop confusing the issue. There is no need for such complicated techniques; moreover, Peterwhy does not want to preserve the whitespace, because that breaks the image linking. What is needed is to trim the whitespace, and the construct that Peterwhy has already used (see the example that he began this thread with, his sandbox also this edit), i.e. {{#if:1|{{{paramname|}}} }} works perfectly well, and since it uses a single parser function, which is built in to the MediaWiki software, is bound to be faster than any template-based alternative. --Redrose64 (talk) 08:45, 29 April 2013 (UTC)[reply]

Problem editing a table

Today on List of vegans, when I added a name to the sortable table and previewed, it wasn't formatted as a table, but as lines of text:

But when I saved, it was properly formatted. This problem only started today. It's happening repeatedly, with more than one browser, and with an account with different preferences. Can anyone think what the problem might be? SlimVirgin ^(talk) 21:20, 28 April 2013 (UTC)[reply]

Let me guess... it began happening after you had saved this edit. What you did there was to split the table into editable sections; as a result, when you edit any of the sections that occur after the start of the table, the table start code won't be present when you preview, but it will be there once saved. --Redrose64 (talk) 21:53, 28 April 2013 (UTC)[reply]

I noticed it today at 17:42, 28 April 2013‎; I think it was okay after the sections were first added, but I'm not sure. We need the subsections because loading the whole table is very slow and hard to edit with; it also leads to edit conflicts. But we also need the code to be present on preview, because people will think they've messed it up and won't save. So it's not just a nuisance factor, it will stop people from editing. What can be done, do you think? SlimVirgin ^(talk) 22:50, 28 April 2013 (UTC)[reply]

Split into subarticles by alpha group: The only way to edit-preview part of a sortable table, with table headers, is to create transcluded sub-articles, where each page shows a part of the total list, but the overall list shows all subarticles transcluded together. For example, with letters A-F, create subarticle "List of vegans A-F" as if being a template, to allow edit-preview with table headers. Each subarticle page would be structured in the following manner:

         <noinclude>
         This is part of the '''[[List of vegans]], names A-F''' as a shorter
         section of the whole list.
         {| class="wikitable sortable plainrowheaders"
         |-
         ! scope="col" style="width:8em;"|Name
         ! scope="col" style="width:35em;"|Occupation
         ! scope="col" style="width:6em;"|Birthplace
         ! scope="col" class="unsortable" style="width:5em;"|Source
         </noinclude>
         |-
         person 1
         |- 
         person 2
         <noinclude>
         |}
         ==References==
         {{Reflist}}
         [[Category:...]]
         </noinclude>

Then, once separated into subarticles as the partial lists, each would be transcluded into the full "List of vegans" by treating each subarticle as if being a template file, trancluded by: Template:J in doubled curly braces. As the list grows, perhaps each subarticle would be sub-divided more, to span just 4 letters of the alphabet, rather than 6 letters A-F. So, plan now for how many letters in each subarticle. Note that each subarticle is truly a WP article (not a template), with lede paragraph and References, plus categories. However, that gives readers the option to view each subarticle if looking for vegans with names under just those letters. -Wikid77 (talk) 23:47, 28 April 2013 (UTC)[reply]

Thanks, Wikid. That sounds a bit complicated, and would it be confusing for new editors? I'm wondering whether it makes more sense just to have regular subsections (A-F, etc); that is, multiple tables. SlimVirgin ^(talk) 01:19, 29 April 2013 (UTC)[reply]

As a screen reader user, I'd prefer to just have multiple tables. The table does work with my screen reader JAWS, but it interprets the headings as part of the table header, meaning that I hear "A–F" along with the edit link when I navigate horizontally through the table; not a showstopper, but quite annoying. A big long table without headings shouldn't lead to edit conflicts, though, unless two users are trying to add people at the same point in the alphabet. Graham87 07:11, 29 April 2013 (UTC)[reply]

Personally I'd go with separate tables for each group, as we have done on pages like List of closed railway stations in Britain: D-F. But to return to the original matter; there is a simple technique, but it must be done carefully. When editing a section within the big long table, make your edit, and then go to the top of the edit window and insert one line immediately after the section header:

{|

and then go for Show preview Having verified the intended edit, make sure that you remove that {| before clicking Save page, because if you don't, you'll create a table-within-a-table, and almost certainly screw up the page formatting. --Redrose64 (talk) 09:10, 29 April 2013 (UTC)[reply]

In general, adding more complexity in order to create a solution to a complex problem is often not the best idea. Go with separate lists. —TheDJ (talk • contribs) 10:01, 29 April 2013 (UTC)[reply]

Many thanks to everyone for the input. Separate tables/sections seems to be the simplest solution. Thanks again. SlimVirgin ^(talk) 17:41, 29 April 2013 (UTC)[reply]

Pictures from Maps+ iPad app

Just a quick question: I have a couple of pictures taken from the Maps+ app on my iPad mini. Is it against any regulations to use them as pictures, and if it was permissible, under what licenses would they be put under. Also, I use a Safari browser on my iPad mini. --JB82 (talk) 23:02, 28 April 2013 (UTC)[reply]

That sounds like they would be copyrighted violations in most cases. The design of the app is owned by IZE, Ltd and the map imagery is owned by Google and it's map providers. There is some information on this topic in our WP:SCREENSHOT page. —TheDJ (talk • contribs) 07:39, 29 April 2013 (UTC)[reply]

Body font size

I am a beginner in CSS. Sorry if it sounds dumb to ask or if this is posted on a wrong page. I want to know how I can increase the body font size so that browsing on ipad could be a little easier. I tried messing with the CSS code but ended up with larger texts in all he toolboxes but not the article itself. — Preceding unsigned comment added by Lauivan (talk • contribs) 09:55, 29 April 2013 (UTC)[reply]

Unwanted global account(s)

I contribute to eight language-specific Wikipedias (CY, DE, EN, ES, FR, GA, NL, SV), with accounts at each, mostly under different user names in each case.

Lately, after logging in to (at least) my CY, NL, and SV accounts I am also being logged in (without being asked, as far as I can see) into

meta.wikimedia.org
wiktionary.org
wikibooks.org
wikiquote.org
wikisource.org
commons.wikimedia.org
wikinews.org
wikiversity.org
mediawiki.org
wikidata.org
species.wikimedia.org
incubator.wikimedia.org
wikivoyage.org

That might be harmless enough, I suppose, except that now whenever I switch from cy.wikipedia, nl.wikipedia, or sv.wikipedia to one of my other accounts I find myself logged in there under the name I used at the wikipedia I have just been visiting, and have to log out and in again under my "real" username for that language -- which is, to put it at its mildest, bloody annoying!

Can anyone tell me, please, if this situation is reversible. I suspect there may be some connection between what is happening here and the "global account" concept (which, as I say, I have never knowingly signed up to). -- Picapica (talk) 11:27, 29 April 2013 (UTC)[reply]

This is one of the "benefits" brought by WP:SUL. My login was created after its introduction, so I'm used to the idea that I only need to log in once and I'm automatically logged in to all the others (although it does have its hiccups). Before we had Wikidata, it was a great boon when fixing interlanguage links (try some of the links at User:Redrose64#Non-English editing). But although I do very little on other Wikipedias now, it's still a benefit for editing on Commons, Meta and Wikidata. --Redrose64 (talk) 12:37, 29 April 2013 (UTC)[reply]

The only way to reverse this "problem" is to use one account. Whether that means you ask local bureaucrats to rename the account where it is not a part of the SUL, or abandon the old accounts, is up to you. I would personally just abandon the old accounts and ask for a bureaucrat or bureaucrat-analog to move the rights from old accounts to whichever you standardize on. --Izno (talk) 12:43, 29 April 2013 (UTC)[reply]

Also, this feature has been in place for a while. It surprises me that you are just discovering it now. --Izno (talk) 12:45, 29 April 2013 (UTC)[reply]

For "a while" read "almost five years". May 27, 2008 is almost a year before my account was created (5 May 2009) but four years after yours. --Redrose64 (talk) 12:59, 29 April 2013 (UTC)[reply]

Try the links on WP:SUL you may be able to unify them yourself. - X201 (talk) 13:01, 29 April 2013 (UTC)[reply]

Thanks for the answers, folks. The thing is, though: I don't want to unify my accounts; I want to UNunify them!

Izno, this problem has (re)surfaced only today. Checking back, I see that I first got rid of it around four and a half years ago (see paragraphs below). I have a strong suspicion that its re-appearance could be connected to my use (for the first time) today of the relatively new "Edit links" feature for updating interwikis, which I did from the Dutch-language nlwiki.

Here is a copy of a previous exchange on this subject from 2008. (I hope the solution offered there will work again!):

I very much regret falling for the invitation to go for a unified login. I have Wikipedia accounts in eight languages, mostly with different usernames. Now when I switch between different language Wps I frequently have to log out and log in each time in order to use these accounts. I don't wish to rename these accounts even if I could (new accounts using my main, English-language name have been set up without my asking for them).

Is there any way I can undo the unified login process so that I can be returned to the happy state I was in before I ever heard of unified login? If not, let this be a reminder to others of the value of the advice "If it ain't broke, don't fix it". :{ -- Picapica 11:24, 5 September 2008 (UTC)

Yes, You can, please request it here, also make sure to have a valid, confirmed email in Your special:preferences for Your own safety, thanks, --birdy geimfyglið (:> )=| 11:26, 5 September 2008 (UTC)

The global account for Picapica was deleted in 2008 as you say [8] after a request at meta:Steward requests/SUL requests. It hasn't been recreated so I guess you refer to one or more other usernames at CY, NL, and SV. What are the usernames? PrimeHunter (talk) 15:49, 29 April 2013 (UTC)[reply]

Those usernames are CY Jac-y-do, NL Torenkraai, SV Femten. It would make life a lot easier for me if none of these was a global account!

Does editing interwikis via the new procedure have anything at all to do with this? Or did I just click on a wrong button somewhare?

(My other usernames BTW -- I've now remembered a couple more -- are: BR Arvran, DE Picapica, ES La voz del oyente, FI Picapica, FR Le choucas, GA Picapica, NO Picapica) -- Picapica (talk) 16:23, 29 April 2013 (UTC)[reply]

Yes, that is what caused the problem. There's simply no (permanent) fix for it other than using one account and one account only, or never editing Wikidata again, which is frankly not going to be an option when phase 2 is in full swing.... --Izno (talk) 21:13, 29 April 2013 (UTC)[reply]

Which is the whole reason behind unified global accounts to begin with. One person, one username across the entire set of projects. It's the ideal - no need to forget (or remember) other userid's. (✉→BWilkins←✎) 21:20, 29 April 2013 (UTC)[reply]

Also see the announcement about enforcing single sign-on here: http://lists.wikimedia.org/pipermail/wikitech-l/2013-April/068937.html --AKlapper (WMF) (talk) 11:39, 30 April 2013 (UTC)[reply]

Wow. Am I reading that right? If an en.wp user has the same account name as anybody who ever SULed on any project, he gets it pushed to some long and unwieldy substitute? That seems like a really, really drastic change from before when you could only co-opt a nearly unused username. And how would you arrange the tracking of all those contributions? And they'd have to log in that way - I'd think half the users affected are going to think they forgot their password. And then they're all going to want to do renames, which they'll need assistance for ... sounds like a class 5 foulup waiting to happen. Wnt (talk) 16:33, 30 April 2013 (UTC)[reply]

To the OP: the weird thing is that it seems like whenever I enable scripts in Firefox (which I only do for Lua programming) I have to manually log in whenever I go to a page on a different project, despite having a SUL. But it works normally the 99% of the time when they're disabled. Wnt (talk) 16:33, 30 April 2013 (UTC)[reply]

Open all articles of a category

Is there a way to open all articles of a catecory (not by click one by one)? With firefox for example? Xaris333 (talk) 18:22, 29 April 2013 (UTC)[reply]

WP:LINKY should do what you want in Firefox. jcgoble3 (talk) 19:29, 29 April 2013 (UTC)[reply]

Thx. Very useful. Xaris333 (talk) 22:21, 29 April 2013 (UTC)[reply]

Caterogies

Is there a way i can find all tha categories i have created? Xaris333 (talk) 19:09, 29 April 2013 (UTC)[reply]

Follow this link and hope the toolserver is in good mood... It seems the only hit is Category:Nea Salamina Famagusta managers. — HHHIPPO 19:22, 29 April 2013 (UTC)[reply]

Thx. Very useful. Xaris333 (talk) 22:21, 29 April 2013 (UTC)[reply]

Announcing the release of the the Wikimedia Commons app for iOS and Android

The Wikimedia Foundation mobile features team is proud to announce the release of the official Commons app for iOS and Android! This mobile application allows users to log in with their Wikimedia account and view, upload, and share their Commons uploads with the image sharing sites of their choice. On Android, you can also batch upload and add categories to your images. We'll be working to expand the features on both versions of the app so that, in the future, you’ll also be able to participate in events like Wiki Loves Monuments and other focused uploading campaigns directly from this app. To let more Wikimedians with compatible mobile devices know about these apps, we'll be running banners on Commons and English Wikipedia to logged in users this week.

Those who are interested in uploading images via mobile on non-iOS/Android (e.g., using BlackBerry devices, running Firefox browsers) can still upload to Commons on the Wikimedia mobile web. Just visit the mobile site of your home wiki, log in, and go to the Uploads page in the left navigation menu.

If you have questions or feedback, please let us know! In addition to Bugzilla, we have a mailing list (mobile-llists.wikimedia.org) and an IRC channel, ##wikimedia-mobile ^connect, where we would be happy to hear from you. Maryana (WMF) (talk) 19:09, 29 April 2013 (UTC)[reply]

Toolserver tools dysfunctional?

It appears that something strange has happened with the Toolserver. I was reviewing a AfC submission (Wikipedia talk:Articles for creation/Marc Danzeisen) and clicked the link (in the AFC template) to do WP:REFLINKS. To my astonishment I got a series of errors, eventually ending up at toolserver saying that the page doesn't exisist as a wiki. To verify I'm not going crazy I also checked Citation bot to see if something was up. It's been 10 minutes and Citation Bot has yet to finish. I do not think this is a web browser problem based on the fact that these links worked not 5 minutes before this oddity. Status Dashboard shows no issues. Hasteur (talk) 19:10, 29 April 2013 (UTC)[reply]

You're lucky that you got a message at all... I often get a blank screen, that's if it doesn't hang or timeout. If you look at past threads on this page, you'll realise that Toolserver has been having problems for months now. --Redrose64 (talk) 20:12, 29 April 2013 (UTC)[reply]

Error trying to restore an image

I had deleted Image:Gracyn Shinyei 2013.jpg earlier today as lacking permission. The uploader informed me that he had sent a letter of permission to OTRS and sent me a copy of it, which looked sufficient, so I went to restore the image and tag it as OTRS pending. However, when I did it, I got this error:

Error undeleting page

Errors were encountered while undeleting the file:

The file "mwstore://local-multiwrite/local-deleted/j/e/e/jee6sxsgsg19i1ji6jalr2k07hv4mcq.jpg" is in an inconsistent state within the internal storage backends
The file "mwstore://local-multiwrite/local-public/c/ce/Gracyn_Shinyei_2013.jpg" is in an inconsistent state within the internal storage backends

Then, I realized that I could view the deleted image, save it, and try to re-upload it myself, but I got this error:

The file "mwstore://local-multiwrite/local-public/c/ce/Gracyn_Shinyei_2013.jpg" is in an inconsistent state within the internal storage backends

Any thoughts other than move it to a different filename?

--B (talk) 21:26, 29 April 2013 (UTC)[reply]

Thanks for taking the time to report this! The problem you are reporting sounds like a potential issue in the code of the servers. If the problem is reproducible, it would be nice if somebody who has this issue could send the software bug to the 'Bugzilla' bug tracker under the product "Wikimedia" and component "File management" by following the instructions How to report a bug. This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance! --AKlapper (WMF) (talk) 11:41, 30 April 2013 (UTC)[reply]

People were having the exact same problem with certain files about a year ago or so. If I remember correctly, the problem was that some files had wrong file access permissions on the servers where they were stored, with the result that the files couldn't be deleted, undeleted or moved. There were discussions about this on Commons at that time, and people were troubled about not being able to delete certain copyright violations. --Stefan2 (talk) 11:48, 30 April 2013 (UTC)[reply]

Prosesize JavaScript

I've been trying to get the JavaScript at User:Dr pda/prosesize to work for me. I've followed the installation instructions (including clearing my cache), but it still doesn't work. Would anyone have any suggestions for what I should do? Alphius (talk) 22:05, 29 April 2013 (UTC)[reply]

Need help removing the background sound from an audio

Hello,

Can anyone here please remove the background noises from this video please - [9]. I really require it, as I'm trying to get it translated into its article, and there is too much noise to understand it clearly.

Thanks, TheOriginalSoni (talk) 01:25, 30 April 2013 (UTC)[reply]

It is a tough problem, for sure. I combined the left and right channels into mono, which helped lower the noise floor somewhat, and greatly increased the signal level, but I was unable to pull the voices out of the static. The big problem is that the noise is in the same frequency range as the voices. Anyway, the resulting file I have is uncompressed WAV audio with a size of 16.4 MB. Let me know if you want to hear it. Binksternet (talk) 02:58, 30 April 2013 (UTC)[reply]

Of course I want to hear it :) Do upload it and link it to me. [Though for upload purposes compressing into mp3 will be better]

Also, the persion doing the tranlation says its most unclear near the beginning and end. So if you can do something about it, that will be good. TheOriginalSoni (talk) 04:10, 30 April 2013 (UTC)[reply]

Thanks for volunteering to help! (I'm the user doing the translation.) Actually, it's the first ~60 seconds that are giving me the most trouble because they are so quiet. The part at the end became more intelligible after I listened to it a few times. Tempodivalse [talk] 04:38, 30 April 2013 (UTC)[reply]

I share audio files all the time with people who know my real name, but I am not so familiar with using an anonymous account. Please see if you are able to get the audio from this shared folder: https://sites.google.com/site/audiobink/. It is a mono mp3 file which is slightly smaller than 4 MB. Best of luck! Binksternet (talk) 13:42, 30 April 2013 (UTC)[reply]

Binksternet, I can't see it, unfortunately. All I get is a blank page. Perhaps you could try another file sharing service? Tempodivalse [talk] 16:48, 30 April 2013 (UTC)[reply]

Lines not wrapping in edit box

I am using IE10 on my laptop with Windows 7. The text in my edit window does not wrap, which is most inconvenient. Is there a setting somewhere that will correct this? • • • Peter (Southwood) ^(talk): 07:00, 30 April 2013 (UTC)[reply]

Replication lag

Anyone know what it's so high (14 hours)? Beyond My Ken (talk) 09:22, 30 April 2013 (UTC)[reply]

Toolserver has been having problems for months. --Redrose64 (talk) 09:36, 30 April 2013 (UTC)[reply]

Cluster s1 had 0h replag, but s2/s5 have 14h: The enwiki wp:REPLAG has been showing zero hours for the s1 cluster, for many days during the past 2 weeks. I am not sure which wikis are on s2 and s5, with the 14-hour replag. However, I have advised the enwiki Lua-cite editors (for wp:CS1 cites) to avoid changing Lua-cite Module:Citation/CS1, as reduced to perhaps once per week or once per 2 weeks, to stop reformatting the 2 million CS1-cite pages "everyday" as before. Meanwhile, the category links still tend to be slow to reset within enwiki itself, even after changing a template used in just a few articles, and must null-edit those few dependent articles to force category-link updates. Also, many of the other-language wikipedias have caught the epidemic navboxaholism, and so a change to their main navbox or infobox templates might cause zillions of cache pages to become out-of-sync and increase the replag. -Wikid77 11:05, 30 April 2013 (UTC)[reply]

Can "×" be made interchangeable with "x" for searching?

A new user pointed out that "This question has to do with all plants on wikipedia that are hybrids, and therefore can contain a special symbol called a cross (×) as part of their binomial name. While it's correct to have the special character '×' in the binomial name of a hybrid, it's neither consistent across all plants on Wikipedia, nor is it terribly useful for users trying to find a certain plant when Wikipedia gives a 404 if I put an 'x' instead of an '×'."

His example was Rubus × loganobaccus with this special character (×) (http://en.wikipedia.org/wiki/Rubus_%C3%97_loganobaccus), which did not work with 'x' (http://en.wikipedia.org/wiki/Rubus_x_loganobaccus).

This has since been handled by redirect, but it is not so easy to redirect them all, because (surprise surprise!) searching for × in the standard form gets you "An error has occurred while searching: The search backend returned an error:" (without giving an error). It can actually go to × if you type it in the go/search box and hit enter, though.

Is it possible to fix the search so that either:

a) any search with × that delivers either an error or no results is reattempted with x, and any search or URL with "x" delivering no results is reattempted with × (hmmm, that is a lot)

or at least

b) A search with × returns all article names containing it?

Wnt (talk) 14:30, 30 April 2013 (UTC)[reply]

I've filed a request on bugzilla as Template:Bug. Andrew Gray (talk) 14:55, 30 April 2013 (UTC)[reply]

SUL account not attached to my account

Can somebody explain me, why my account at nl.wikitionary wasn't corectly attached to my SUL account, although it was automatically created (as stated in the log)? I know that I visited the page logged in a few months ago and sadly there is no email set in the preferences. mabdul 16:04, 30 April 2013 (UTC)[reply]

@@ Line 811: / Line 811: @@
 ::::I share audio files all the time with people who know my real name, but I am not so familiar with using an anonymous account. Please see if you are able to get the audio from this shared folder: [https://sites.google.com/site/audiobink/ https://sites.google.com/site/audiobink/]. It is a mono mp3 file which is slightly smaller than 4 MB. Best of luck! [[User:Binksternet|Binksternet]] ([[User talk:Binksternet|talk]]) 13:42, 30 April 2013 (UTC)
+:::::Binksternet, I can't see it, unfortunately. All I get is a blank page. Perhaps you could try another file sharing service? [[User:Tempodivalse|<font face="Georgia">'''Tempodivalse'''</font>]] [[User talk:Tempodivalse#top|<font face="Georgia">[talk]</font>]] 16:48, 30 April 2013 (UTC)
 == Lines not wrapping in edit box ==