Jump to content

Wikipedia:Village pump (technical)/Archive 112

From Wikipedia, the free encyclopedia

New #time: TimeZone parameters

MediaWiki's new #time(TimeZone) arguments added in 1.22wmf2 that are supposed to return if it is DST or not don't work... Anyone know more about this or are there plans to fix this? Technical 13 (talk) 21:44, 16 May 2013 (UTC)

#time returns the time in UTC (verify: UTC), which never has DST. #timel uses the server's local time, which for enwiki is also UTC (verify: UTC). On other sites with different local timezones, such as dewiki with CET, you can see that it works as you're expecting. Anomie 21:22, 19 May 2013 (UTC)
That is not working as I would expect it. I would expect #timel; to return the local time based on the user's preferences. Technical 13 (talk) 21:32, 19 May 2013 (UTC)
That would fragment the caches, and so is unlikely to happen for the same reasons we don't have a magic word to give the username of the user currently reading the page and things like that. Anomie 00:54, 20 May 2013 (UTC)
With regard to your last point (about usernames and caching), I have seen at least one wiki use a bit of js code to emulate this. Not being a techie and all, I don't know if this is verboten. Killiondude (talk) 03:23, 20 May 2013 (UTC)
Since it uses JS, that gets run client side so it doesn't affect the caches. Legoktm (talk) 23:18, 21 May 2013 (UTC)

How do you test for a redlink?

I'm about to write a perl script to strip redlinks from a (wiki-marked up) list of links, but I don't have a clue where to start. I wish redlinks could be specified in a regex.

How would I go about testing the links on a WP page for redlink status? The Transhumanist 01:45, 19 May 2013 (UTC)

User:MZMcBride/stripredlinks.js is an old script that does this by looking at the rendered HTML. In a Perl script, you'd need to use the MediaWiki API to check each title (or preferably batch-check titles) to see if they exist on a particular wiki. But link existence can be very tricky with interwiki prefixes, namespace aliases, etc. --MZMcBride (talk) 01:50, 19 May 2013 (UTC)
How does one use/activate this script? And what does it do exactly? The Transhumanist 02:55, 19 May 2013 (UTC)
It's activated the same way any user script is activated: importScript('User:MZMcBride/stripredlinks.js'); in your relevant /skin.js subpage.
You should be able to read through the script fairly easily. It takes a list of pages and temporarily removes the red links. For example, if you have the following list:
This script adds a link to the sidebar ("Remove red links"). When you click this link, the list will read:
Until you next refresh the page (i.e., temporarily). Hope that helps. --MZMcBride (talk) 03:19, 19 May 2013 (UTC)
Ah, it adds a link to the sidebar. That's the part that wasn't obvious from your initial description. Thank you for your patience with my questions.
By the way, I don't understand that script at all. Which line actually identifies the red links as red? And how does it do it? The Transhumanist 04:03, 19 May 2013 (UTC)
i am not familiar with the specific script, regarding the "how is it done" question: it is very easy to do in a javascript which runs on wikipedia itself. red links have the CSS class "new", and there is absolutely no reason for anything which is not a redlink to have this class, so basically a super- simple expression such as $('a.new'); produces a list of all redlinks. now, what you can do with it in the script is a different matter. the script described above hides them and then exposes them back. what you want to do is to generate a list on the perl side which you can work with. as to "regex": basically you want to scan the html for "a" element with class="new". should not be that difficult. you can also, as mentioned above, use the API to get the list of redlinks. קיפודנחש (aka kipod) (talk) 05:11, 19 May 2013 (UTC)
(edit conflict) Fair enough. I've documented the script: User:MZMcBride/stripredlinks.js. --MZMcBride (talk) 05:17, 19 May 2013 (UTC)
The way I prefer to test for redlinks is with jquery like $('a[href*="&redlink=1"]').whatever you want to do with it Hope this is useful to you. Technical 13 (talk) 12:12, 19 May 2013 (UTC)
"redlink=1" is in the API-generated HTML source text. You're talking about scraping the html page, aren't you? The Transhumanist 09:56, 21 May 2013 (UTC)

Prerequisites for technical articles

The text below is a compilation of quotes from #wikipedia and ##math on freenode. Also see Prerequisites Project. Editingeddie (talk) 22:08, 20 May 2013 (UTC)

It seems it's time for Wikipedia to include a new section to its technical articles (math is the best example): prerequisites.

It's not going to be easy, but from giving our readers exhaustive prerequisites trees to not trying anything at all and letting them find their way around there's a long distance. There's always *some* minimal content to: "here's a non-exhaustive list of topics that the reader is assumed to be familiar with before reading this". Furthermore, a work-in-progress prerequisites tree (like a Debian dependency tree) would be of great encyclopedic value itself.

Again, I am aware how difficult this can be; it's not like I can't find tens of arguments against it myself. I just think there are some solid reasons to give it some thought. Perhaps fewer and less solid than the reasons to do nothing, but that's just normal for a concept that many people may have not even thought about. So perhaps if we gave it a chance...

The most exciting thing about this new editorial approach is that it would *finally* begin to address the "too technical" problem *without* affecting accuracy/completeness.

How can we get this started? Does it need some voting or something? Where could we meet and talk about it? Perhaps we could use ##wikipedia-prerequisites channel on freenode to talk about it (I just created it provisionally). — Preceding unsigned comment added by 79.115.8.76 (talk) 10:23, 20 May 2013 (UTC)

See {{Pre-read}} for a possible wording. ShakespeareFan00 (talk) 10:40, 20 May 2013 (UTC)
A good place to talk about it would probably be Wikipedia talk:WikiProject Prerequisites Project. For wider input, the idea lab would be a good place to go. If you're looking to create content guidelines for this, take a read of Wikipedia:How to contribute to Wikipedia guidance. Proposed guidelines normally go through a process like RFC to be approved by the community (RFCs typically use !voting). – PartTimeGnome (talk | contribs) 22:01, 21 May 2013 (UTC)
I've left a comment at Wikipedia talk:WikiProject Prerequisites Project. – PartTimeGnome (talk | contribs) 22:15, 21 May 2013 (UTC)

Watchlist changes since last login

I would appreciate it if my Watchlist noted which of the pages listed have been changed since I last logged in. There's something similar when I look at the history of a page on my watchlist ("Updated since your last visit"). Any chance? Thanks. (p.s. why isn't 'watchlist' in our spellcheck dictionary?) --Ring Cinema (talk) 13:57, 20 May 2013 (UTC)

This is already implemented in MediaWiki, but disabled here because some people... loudly complained when it was enabled. You could probably have it enabled back, just ask an admin. Matma Rex talk 14:29, 20 May 2013 (UTC)
See Wikipedia:Customizing_watchlists. And i'm not going to put myself into that cesspit again, but yes, it's still ridiculous to be disabled by default. There were several very good proposals about painting this bike shed. —TheDJ (talkcontribs) 15:11, 20 May 2013 (UTC)
(edit conflict) i do not think the last statements are correct. to the best of my knowledge the requested functionality is not implemented in mediawiki, and was never active on enwiki. (i think the gentlemen who answered did not read the question carefully enough: he is talking about "change since last login", not "change since last visit").
i am not sure what the OP meant by the p.s.: where is this "spellcheck dictionary"? the only one i am aware of has nothing to do with wikipedia, and is part of my browser. one can't expect wp to shove entries into one's browser's dictionary, but most browsers make it easy enough to add entries yourself. peace - קיפודנחש (aka kipod) (talk) 15:14, 20 May 2013 (UTC)
It is indeed correct, $wgShowUpdatedMarker has been enabled for over a year, see Wikipedia:Village pump (proposals)/Archive 83#Enable "Show changes since last visit" on watchlist. Current discussion is at Wikipedia:Village pump (proposals)#"Updated since last visit" markers. I do intend to re-enable it using colored bullets, which was not previously possible due to limits in CSS which have since been adresses. Edokter (talk) — 15:32, 20 May 2013 (UTC)
$wgShowUpdatedMarker is a different matter. this has to do with bolding "changes since last visit", and the OP was asking about a new functionality: show changes since last login. i do not believe this functionality is implemented by mediawiki. קיפודנחש (aka kipod) (talk) 15:38, 20 May 2013 (UTC)
It basically boils down to the same thing. Changes since last login is not possible; to my knowledge, MediaWiki does not store login activity. Edokter (talk) — 15:41, 20 May 2013 (UTC)
It may not be possible on en.wiki but as an admin on a Wikia I know it stores the last edit and last login of the other admins, possibly all users.--Gilderien Chat|List of good deeds 18:06, 20 May 2013 (UTC)
It does for all users, but that's a Wikia-specific extension, not core MediaWiki. Maybe the OP can clarify if they really meant since last login or since last visit. I myself would really like if the watchlist would not only mark which pages have been modified since my last visit, but also which revisions. Especially for pages like this one. — HHHIPPO 20:44, 20 May 2013 (UTC)
For highlighting new revisions since your last watchlist visit, try User:Ais523/watchlistnotifier.js. In addition to its stated function of adding a notice to each page of what the most recent edit on your watchlist is (which is very unobtrusive and easy to ignore), it will also, when viewing the watchlist, bold all new revisions since the last time your watchlist was loaded, provided that the last time the watchlist was loaded was within the same browser session. Note that it will not do this on the first watchlist load of each browser session, though. jcgoble3 (talk) 22:16, 20 May 2013 (UTC)
Yes, I did mean since last login. I tried the gadget (and thank you everyone for responding!) and it is not bad but to me it would be nice to know what has happened since my last visit. Such a feature chains nicely and doesn't repeat itself. Since I would like it, maybe others would like it, too. Thanks again. --Ring Cinema (talk) 23:37, 20 May 2013 (UTC)

Jcgoble3, the gadget you describe is in a sense the opposite of what I'm interested in. Instead of clueing me in at the time I sign in about changes, it only lets me know about changes since I logged in. I want to know about changes since my last login -- or better yet, since my last session ended. Isn't it obvious how useful this would be? --Ring Cinema (talk) 17:30, 21 May 2013 (UTC)

Problem with translation

I can't translate from english to greek. Does anything happen? Nothing change in User:Xaris333/vector.css. Xaris333 (talk) 18:34, 20 May 2013 (UTC)

Vector appears to be broken, see "Something's wrong again" above. --j⚛e deckertalk 18:37, 20 May 2013 (UTC)
  • Also some "Cannot find server" of other-language wikipedias: There were temporary periods (such as near 14:00, 21 May) where clicking interwiki links led to Cannot-find-server of the German WP (dewiki) or Greek WP (elwiki) websites. However, interwiki access has been restored. -Wikid77 (talk) 14:22, 21 May 2013 (UTC)

A real edit conflict

What happened here? It seems to have completely wiped the previous edit. Edokter (talk) — 18:46, 20 May 2013 (UTC)

  • That example does appear to be a failure of two cases of "New section" at wp:ANI, where the 2nd overrides the 1st, 3 minutes later (18:39, 20 May 2013), and both edit-summaries said "new section". Perhaps there is a prior Bugzilla ticket for this. However, sometimes people force the new content, to override an edit-conflict with their new message erasing the prior one, which has happened to me twice (yet another reason to auto-correct edit-conflicts rather than give users the option to erase the conflicting text). It is also likely someone edited a prior thread and just completely replaced it with new ==Header== and contents (which I have almost done twice, forgetting I was tagging onto a prior message), and that would be a nice warning as a new feature, during edit-preview (as: "Warning: Edit replaces prior contents"). But I won't insist the evil "Edit-conflict" made them resort to hijacking the contents of a prior thread. -Wikid77 (talk) 23:18, 20 May, 11:24, 21 May 2013 (UTC)

Need help with navbox

Template:Billboard Music Award categories shows correct Wlinks when in edit mode, but when I tried to click on a link I got sent to the wrong place. I assumed it was related to the problem causing "{{Navbox" to appear before the navbox, but my attempt to fix both problems seems to have just made a mess.— Vchimpanzee · talk · contributions · 20:17, 20 May 2013 (UTC)

I think I solved the problem. Looking at the history, I found vandalism and merely restored the template to what it looked like before the edits by the vandal, and removing brackets that should not have been closed.— Vchimpanzee · talk · contributions · 21:04, 20 May 2013 (UTC)
Not sure why you need both Template:Billboard Music Award categories and Template:Billboard Music Awards? Plastikspork ―Œ(talk) 03:00, 22 May 2013 (UTC)

The Transhumanist 03:40, 21 May 2013 (UTC)

That's a pretty vague question. Could you specify where you're wanting to take this discussion? — This, that and the other (talk) 09:47, 21 May 2013 (UTC)
It has code in Linker.php ([1]) that decides whether to add class "new" to links (which makes them red through CSS). The check goes through the LinkCache ([2]), which ultimately (line 227) looks in the page DB table for a page with the given name. Ucucha (talk) 11:56, 21 May 2013 (UTC)

ogg files in Firefox

File:A through Z in Morse code.ogg when played in Firefox cuts off the "Z" at the end and it is not heard. Confirmed with other users, it is not just me. Any ideas what's going on here? SpinningSpark 04:57, 21 May 2013 (UTC)

The file description page lists it as a 38-second file, yet playing it in Chrome shows that it is actually 40 seconds long. Firefox cuts it off at the stated 38 seconds. Possibly a bug with MediaWiki's handling of the file? jcgoble3 (talk) 06:17, 21 May 2013 (UTC)
So what can be done about this - if anything? SpinningSpark 11:02, 21 May 2013 (UTC)
First, file a bugreport at bugzilla. Then, as an intermediary step, re-encoding the file might help. Probably, there is some inconsistency in the timestamping of the audio packets, that the Server side parser is not able to handle properly. Re-encoding the file might realign those timestamps, and cause the file to work. —TheDJ (talkcontribs) 11:52, 21 May 2013 (UTC)

Avoiding aliasing (of SVG files when rendered as PNG)

Hi, I'd want to avoid aliasing of generated SVG files and would like to know which native resolution of the SVG file would least likely be subject to aliasing. I'm free to specify native height and width for the svg file. I asked this question at a less frequently used page before Help_talk:Visual_file_markup#Avoiding_aliasing. Additional info (and links to SVG images which show aliasing after conversion to PNG) is there and it was suggested to bring up the topic here. Thanks! --HeWhoMowedTheLawn (talk) 21:04, 21 May 2013 (UTC)

This is the same thread that I mentioned at #Image preparation advice forum above. --Redrose64 (talk) 22:31, 21 May 2013 (UTC)

Report days since Edit-conflicts still not fixed

Related: "#Autocorrecting Edit-conflicts as Edit-merges".

Another option, to help focus on fixing major issues, might be to have a frequent report, as with "Days since Edit-conflicts still not fixed". In this case, I am thinking about the type of edit-conflicts where editing a bottom section, to add another new section, should be considered an automatic correction, and so we could count the days since that bottom-section problem has not been fixed. However, how far back should the count extend? Perhaps start one year ago, or what date would more fairly reflect how long people have wanted the edit-conflicts to be fixed. Also, which template(s) should be used to show the elapsed time. Perhaps a years+days counter would be better, such as:

"4 years, 257 days, and edit-conflicts still not fixed"

That seems better than showing thousands of days. Then, we could show the not-yet-fixed counters in pages about edit-conflict issues. Any other suggestions? -Wikid77 (talk) 17:27, 18 May 2013 (UTC)

  • New Template:Days_since to show years/days: I have created another date-utility template, to focus on counting days (not just months/years) since a specific date, as Template:Days_since. The related help-page, Help:Edit_conflict, had been created over seven years ago, on 24 November 2005, and so:
  • {{days since|2005|11|24}} → 6946
But perhaps the year parameter should be dated back, even further, based on other pages where people discuss needing to fix the edit-conflict problems. -Wikid77 18:34, 18 May 2013 (UTC)
And how does that help ? As long we are not using the parsoid system, edit conflicts will be inevitable, and even with parsoid, we would be subject to them until we add live collaborative editing. Please add something useful instead of being pointy. —TheDJ (talkcontribs) 20:34, 18 May 2013 (UTC)
  • Many would-be edit-conflicts are already avoided but others can be fixed: Thank you for noting the parsoid issues. I guess not many people realize that section-based edits are already retro-inserted into previously-edited pages, to avoid edit-conflicts (not "inevitable") even though the prior page is in true conflict with the next revision generated. It does not take much additional logic to treat portions of text as similar to section-editing, or the unchanged end-section text as an implicit new-section edit (any person who appends to end-section 'n' unchanged, is creating implicit new section 'n2' or 'n3' when conflict). Another issue, which makes many edit-conflicts seem hopeless is the current text-differencing algorithm which becomes confused by a line deletion or insertion. Instead, an edit-conflict can be auto-corrected by re-syncing on the prefix/suffix sections of other lines, rather than just the complete match against whole lines (ignoring the power of prefix/suffix matches). By that method, many partially-changed lines can be recognized as equivalent to the prior unchanged lines, and even some interleaved changes to every other line could be re-synced during an edit-merge, as in User:A changes lines 2, 4, 6, 8, 10, and 12, meanwhile User:B changes lines 1, 3, 5 (etc.), but inserts new lines, and the result is: "Auto-corrected edit-conflict, no difficulty at all". The 3 versions would be merely line-for-line recombined, treating the current saved version as the base, and then treating the differences against the prior version as the new text (skip lines 2, 4, 6, 8, etc.). In complex cases, the merge could be reported as "too extensive" to autofix. I know when this is implemented, the developers will be accused of "black magic" and watched suspiciously for their "alien powers" of advanced technology to solve the impossible edit-conflicts, but I think we could even explain the process to new users, as to how the partially changed lines are spotted as being re-sync points which allow the amazing auto-correction of numerous wannable edit-conflicts. I promise you, this will be awesome fun, as the finest wizardry, for the developers who agree to update the software to auto-correct these easy-to-merge conflicts (as a 3-revision synchronization). In fact, we could even have a user-preference: "Accept auto-corrected edit-conflicts as edit-save" to make it seem there are almost no edit-conflicts to busy editors. I think the imagined difficulty comes from text-book examples with short-line text, but because our editors create such ultra-long lines of text, then the re-sync of numerous changes can be easier to spot by prefix/suffix matches than in short-line, text-book cases. Another issue, but rare, is lookahead of several lines to re-sync, as in repeated groups of similar test-data lines. I have studied these issues for many years, so that is why I knew the many secrets. -Wikid77 (talk) 22:03, 18 May 2013 (UTC)
Who are you preaching to ? Devs already know this, you are not doing it, and other readers are not served with this —TheDJ (talkcontribs) 08:52, 19 May 2013 (UTC)
Are you trying to imply the developers are hopelessly incompetent, while knowing how to fix edit-conflict text, they just cannot seem to fix it, and the readers do not want to know about that? Sorry, I am not buying that line of reasoning, and I have seen evidence to the contrary that the developers could fix the edit-conflict pages, at the very least, to show an "Edit-merge" dialog of the retro-inserted new text for an editor to resume editing after an edit-conflict occurs. Please remember, when editing the hot-topic articles or busy discussions, then edit-conflict is the #1 problem with Wikipedia. It happens many, many times every day. Several people have even noted to click "New section" to avoid edit-conflicts on the bottom section, so I do not believe other readers do not care about fixing edit-conflict text. -Wikid77 (talk) 13:44, 19 May 2013 (UTC)
  • Edit-merge already done for separate portions but 2-reply conflict needs consensus: It seems there is already extensive auto-correction for many edit-conflicts since 2004, when re-combining separate parts of a page, such as the 1st editor changes the infobox parameters, while 2nd editor changes a paragraph, and the 2nd editor's paragraph is inserted with the 1st editor's infobox. So, I apologize for the misunderstandings. The next fix would be for 2 replies added after the same line, in a talk-page, or a list (etc.). However, the editor community needs to reach a consensus, so the developers would have a resolution, to append a 2nd reply, after the 1st reply, at the same line number, which is currently treated as "edit-conflict" and extremely common in fast-moving talk-pages. The developers have already finished "90%" of the bigger, complex Edit-merge operations, and what is left is to decide the community's choice as to which order to append two replies at the same line number. Perhaps we need an RfC to decide that issue. -Wikid77 (talk) 23:32, 20 May 2013 (UTC)

"From Wikipedia, the free encyclopedia" bug

I have noticed today that for any article I visit, instead of just saying From Wikipedia, the free encyclopedia below the title, it says teSub">From Wikipedia, the free encyclopedia. Is this affecting anyone else?  Liam987(talk) 02:15, 22 May 2013 (UTC)

I don't see a problem. It sounds like something got cut off, since the id for that element is siteSub. Are you still having a problem? Plastikspork ―Œ(talk) 02:52, 22 May 2013 (UTC)
@Liam987:. It's a bug in the wikitrust script that you had installed. I have disabled the script for you. You also had two other script loading issues that I corrected. You might want to consider using the AFC gadget from your preferences and disabling that script in your common.js. Also, you load at least igloo twice (once from your common.js and once from your vector.js). —TheDJ (talkcontribs) 20:11, 22 May 2013 (UTC)

Ref template problem

In the notes section for 1987 Eastern Michigan Hurons football team, there is a problem with the display of the date in which the note was retrieved. This should not be hard to find, seeing as there is only one note. AutomaticStrikeout  ?  02:46, 22 May 2013 (UTC)

Fixed it. Two column referencing is not a good idea for only one reference :) Thanks! Plastikspork ―Œ(talk) 02:50, 22 May 2013 (UTC)
Thank you. I should have checked that. AutomaticStrikeout  ?  15:42, 22 May 2013 (UTC)

{{Factiva}} appears to no longer be working, in that it links to a non-existent offsite location. Does anyone know if there is another resource available that links directly to a Factiva resource so that users can click through and verify its validity? Lankiveil (speak to me) 11:46, 22 May 2013 (UTC).

Resolved

As pointed out on Talk:Plastic number by another user, in the infobox in Plastic number, the Continued fraction link and the adjacent reference are not clickable in Firefox. I can’t see anything in the code that would distinguish it from the other links, which work fine, and it also works fine in Opera. Can anyone explain this weird behaviour?—Emil J. 12:22, 22 May 2013 (UTC)

It is probably javascript related: the link is clickable (in Chrome) for a fraction of second before the page is fully loaded. Ruslik_Zero 12:54, 22 May 2013 (UTC)
It is also related to template {{Irrational numbers}}: if it is removed the links become clickable. Ruslik_Zero 13:13, 22 May 2013 (UTC)
If the template is replaced with nonempty text, it is still not clickable, so I don’t think it is directly related. On the other hand, removing the entire table row with the template makes Algebraic form nonclickable. It would seem that the loss of clickability only affects the fifth row of a table.—Emil J. 14:17, 22 May 2013 (UTC)
It has to do with the <math> in the main text, to the left of the table. When the math is rendered, after the initial display of the page, extra vertical space is needed. All the links (or parts of links) on the same height as this inserted space are not clickable. I would guess that's because the links are now at a location that didn't exist when the browser scanned for clickable areas. No idea how to to fix this, except for avoiding <math> next to links. — HHHIPPO 14:39, 22 May 2013 (UTC)
(edit conflict) My console is telling me that it is a jax.js error when the link stops being clickable... Researching more. Technical 13 (talk) 14:44, 22 May 2013 (UTC)
Okay, so I "fixed" it by wrapping the <math>...</math> in a <div style="display: inline-block; width: 300px;">...</div> so that it would prevent the math from taking to whole width of the screen and limiting it to what it needs to display the formula. This should probably get someone to submit a bug report. Probably could even skip the div and insert the style into the math tag, not sure... Technical 13 (talk) 14:51, 22 May 2013 (UTC)
From the conversation, I'm assuming you all have MathJax enabled in your preferences ? —TheDJ (talkcontribs) 19:33, 22 May 2013 (UTC)
I can't speak for the others, but I do. Technical 13 (talk) 19:42, 22 May 2013 (UTC)
I filed a bugreport and will also file it upstream —TheDJ (talkcontribs) 19:46, 22 May 2013 (UTC)
Disabling the position: relative; rule for .MathJax_Display seems to fix the problem without any adverse effects. In fact, we might as well kill display: block;, as it is already embedded in a block level element (<dd>). Edokter (talk) — 19:49, 22 May 2013 (UTC)

bad gateway

I've gotten occasional sporadic "Bad Gateway" returns from the API in my own bots the last few days, and entirely separately from the WP:AFC script. So, I'm pretty sure something's wrong on the server side, anyone have any clue? --j⚛e deckertalk 17:37, 22 May 2013 (UTC)

I've had about a dozen or so Bad gateways over the last week. Don't know what it's from though. 64.40.54.104 (talk) 01:45, 23 May 2013 (UTC)

Where are the skins?

Why are there now only four skins in the preferences page? What happens if I want a custom skin? --Nathan2055talk - contribs 17:53, 22 May 2013 (UTC)

They were deprecated and removed. See Turning off outdated skins on meta for more information.--Jorm (WMF) (talk) 18:29, 22 May 2013 (UTC)
Also Wikipedia:Village pump (technical)/Archive 110#Classic skin and CSS; I think other places too. --Redrose64 (talk) 18:38, 22 May 2013 (UTC)

Data inclusion from Wikidata by labels is now available

I just wanted to let you know that it is now possible to include data from Wikidata using the property's label (not just the ID). So in essence this means that you can for example use {{#property:continent}} instead of {{#property:P30}} if you don't want to remember the ID there. Both of these would return "Europe" if used in the article about Spain for example. --Lydia Pintscher (WMDE) (talk) 21:58, 22 May 2013 (UTC)

Problem in conversion from wiki code to HTML

Hello people,

I enter this wiki code :

<code style="background: yellow; color: dimgray;">A B C </code><code style="background: pink; color: darkgreen;">D</code>

I get this result :

A B C D

The space between C and D is not in "code", and gets no colour background.

The HTML code generated is :

<code style="background: yellow; color: dimgray;">A B C</code> <code style="background: pink; color: darkgreen;">D</code>

There is a problem in the conversion from wiki code to HTML.

Thank your correcting that, and have a nice day.

--Nnemo (talk) 20:15, 18 May 2013 (UTC)

@Nnemo:Replace the space after "C" with an explicit non-breaking space: &nbsp; Voilà! A B C D Ignatzmicetalk 20:35, 18 May 2013 (UTC)
This is the builtin HTML Tidy system at work, (over) correcting for oft made mistakes in HTML authoring. —TheDJ (talkcontribs) 20:37, 18 May 2013 (UTC)
I did not know there is a built-in applying of HTML Tidy. Not a so good idea. --Nnemo (talk) 21:51, 18 May 2013 (UTC)
What's worse, we are pretty much dependent on it. I've tried importing Wikipedia templates to a Mediawiki instance with HTML tidy turned off and one often finds places where tables, spans, and divs were never closed properly but local users here don't actually notice because tidy has been hiding the mistakes. Dragons flight (talk) 01:51, 19 May 2013 (UTC)
This is yet another good reason for turning off HTML Tidy. Currently HTML Tidy hides errors under the carpet. If we turn off HTML Tidy, we will find the templates broken, and we will soon correct them. --Nnemo (talk) 18:09, 20 May 2013 (UTC)
If the HTML is sufficiently broken to display incorrectly in a browser, the chances are HTML Tidy will also do the wrong thing. Hence badly broken HTML is easy to spot even with HTML Tidy.
Also, different browsers handle bad HTML differently: an editor's browser might display it as intended, so they don't know to fix it. Some readers could see the page as broken, however. By ensuring the HTML sent to browsers is valid, HTML Tidy makes it more likely that everyone sees the page the same – consistently broken or consistently as intended.
Furthermore, most Wikipedia editors are not technically minded. If HTML Tidy was not there to correct the broken HTML before sending it to the browser, the level of invalid HTML output by Wikipedia would probably grow faster than technically-minded editors could correct it. – PartTimeGnome (talk | contribs) 21:16, 23 May 2013 (UTC)
Thank you Ignatzmice, but here I am not looking for a way to circumvent the bug. I was. And I discovered that this bug is really nasty. But now I have done the workarounds I needed. The character you propose is different from the space character, this has consequences. --Nnemo (talk) 21:51, 18 May 2013 (UTC)
  • Nest 2nd tag inside end of 1st tag: When a colorized tag ends with a trailing space, then another tag (perhaps null-span: "<span/>") needs to be nested within that tag to preserve the color of the non-breaking trailing space. So some options:
  • <code style="background: yellow; color: dimgray;">A B C <code style="background: pink; color: darkgreen;">D</code></code> → A B C D
  • <code style="background: yellow; color: dimgray;">A B C <span/></code><code style="background: pink; color: darkgreen;">D</code> → A B C D
If the text wrapped after "C" then the trailing space would still appear at the end-of-line, with the next line having letter "D". Although the request was to note/fix the bug, due to restrictions of HTML Tidy, then other editors need to realize how a nested-tag or null span-tag "<span/>" must be used to preserve the trailing-space color inside the outer tag. The use of mixed-color labels can be an issue in annotated maps or images. -Wikid77 23:24, 18 May 2013 (UTC)

Hacking in crosswiki watchlists with a JavaScript gadget

Hi. Crosswiki watchlists (bugzilla:3525) are still a way off. But I'm wondering how difficult it would be to hack up something in the meantime using a JavaScript gadget.

Here's the basic idea: a user would go to Special:Watchlist on his or her home wiki and at the top there would be a prominent drop-down menu that defaults to the user's current wiki (e.g., "en.wikipedia.org"). The drop-down menu would be configured on a per-user basis to list other wikis (e.g., "meta.wikimedia.org" and "test.wikipedia.org").

If the user selects one of these domains in the drop-down menu, the watchlist content would reload (staying on the same domain and hopefully not requiring any browser window refresh). Ajax would be used to pull watchlist content via the MediaWiki API from remote wikis. Watchlists already have support for external tools pulling their contents via a watchlist token.

Here's where I'm having difficulty mapping out this feature in my head:

  1. How would you store which wikis to feature in the drop-down menu on a per-user basis? We don't want to list all possible wikis as the list is simply overwhelming and most users just want to keep an eye on one or two other wikis.
  2. How would you store the watchlist token on a per-user basis in a place that's both configurable, but still allows the user to keep the token private?

Between cookies, local storage, JavaScript obfuscation, and possibly the action=options MediaWiki API module, I feel like figuring how to store this information in a persistent, yet private, way should be possible. Thoughts? --MZMcBride (talk) 01:10, 19 May 2013 (UTC)

Discussing this with people smarter than me, it seems like CORS could work to grab the remote HTML to solve question 2 (i.e., instead of using watchlist tokens + RSS, just grab the generated watchlist HTML), assuming SUL can be relied upon to log the user in. --MZMcBride (talk) 01:25, 19 May 2013 (UTC)
Once they complete the SUL finalization, that shouldn't be a problem. Theopolisme (talk) 13:08, 19 May 2013 (UTC)
SUL finalisation will ensure that everyone has an account they can use on every WMF wiki. It won't force them to be logged in to it, though. There have been various cases where people have needed to log-in manually to our sister projects, despite having an SUL account. (This is possibly due to security features in modern browsers.) Hence, you can't rely on SUL to log a user in even once SUL finalisation is complete. – PartTimeGnome (talk | contribs) 22:56, 23 May 2013 (UTC)

Weird problem in adding categories to an article

For two days I've been trying to add a category (Category:Social movements, or new Category:Social movements in South Korea) to article New Community Movement. I was trying to use HotCat (which I use commonly, and which still seems to work perfectly fine on all other articles I've tested) but each time I tried to save the edit to the NCM page, I'd lose connectivity to Wikipedia in all my browsers for ~1 minute or so. I was unable to replicate this issue in any other article, and I was able to add the category without any problems using wiki syntax regular editing. Any ideas what is causing this problem? It's not a browser issue (happens in Firefox and Chrome), nor is it an accidental server downtime (I was able to replicate it numerous times over the last 24h). I haven't yet had the time to try it out on another computer (HotCat requires log in). Oh, the block or whatever that is affects all wikipedias (I can't access pl or ko) but I can access other WMF sites (meta, wikibooks, etc.) Can anyone else replicate this? I can still replicate this with other categories in that article (just tried to add Category:1970 establishments in South Korea to that article and got the same ~1 minute can't access wikipedia servers). --Piotr Konieczny aka Prokonsul Piotrus| reply here 03:05, 21 May 2013 (UTC)

I encountered no problem in Chrome. Ruslik_Zero 19:35, 21 May 2013 (UTC)
wild hypothesis: this has something to do with the upgrade to 1.22wmf4. basically, whenever there is an upgrade, it is possible that the browser still keeps one of the old JS files in cache, and from then on, stuff can happen.
usually the remedy is a full flushing of the cache. in the "big 3" under windows (ff/ie/chrome), this is done by Ctrl+⇧ Shift+Delete (not to be confused with the Three-finger salute) and selecting "Empty the cache" or "Delete temporary files" or simply "cache".
The fact (guess, actually) it's caused by "stray file" in your browser, is the reason why others can't reproduce: they do not have same "leftover files" as you do. please clear the cache and retest. peace - קיפודנחש (aka kipod) (talk) 21:15, 23 May 2013 (UTC)

.texhtml revisited

In September 2012 there was a proposal to redefine the default typeface for class="texhtml", but there was little interest in it (as I realize now, because of conservatism of WP:WikiProject Mathematics and too narrow venue (MediaWiki_talk:) for the final proposal). Later I occasionally noticed that when MathJax downloads its fonts, they can be reused by class="texhtml" (with such declarations as in user:Incnis Mrsi/common.css) in the absence of locally-installed fonts, at least in Firefox. Now I found a case where this hack could be rather useful: the article has both <math> and class="texhtml" formulae, but a user without locally-configured fonts with angle brackets sees them with MathJax, but does not see them in {{math}} because my proposal of 2012 was rejected. Incnis Mrsi (talk) 20:05, 22 May 2013 (UTC)

There is no guarantee that this works with {{langle}} and {{rangle}}; it may not have those characters at the same unicode positions. I'm willing to set up a testcase, but I'm still opposed to the inconsistent behaviour it will introduce depending on the presence of any <math> tags on the page. Either that, or the font should be loaded for .texhtml by default. I don't know if we want that; font-download may go through the roof. Edokter (talk) — 22:11, 22 May 2013 (UTC)
Assuming a good faith in Edokter’s “it may not have those characters at the same unicode positions”, I resort to conjecture that he did not enable MathJax. Yes, these have the same code points: U+27E8 MATHEMATICAL LEFT ANGLE BRACKET and U+27E9 MATHEMATICAL RIGHT ANGLE BRACKET. Incnis Mrsi (talk) 06:23, 23 May 2013 (UTC)
I do have MathJax enabled (Nageh's script). I did some tests with both the MathJax_Main (Computer Modern) and STIX fonts: They look horrendous inline (though STIX looks slightly better). The math template main goal is legibility; using webfonts for inline formulae negates this. So I'm still opposed to introducing this wholesale to solve a single problem. Edokter (talk) — 20:11, 23 May 2013 (UTC)
When I thought better, I also realized that the solution is faulty because would deprive readers who have neither MathJax nor good fonts. IMHO, a more global approach has to be considered. Incnis Mrsi (talk) 20:38, 23 May 2013 (UTC)

Errors from simple "exact phrase" searches

(From a question at Help talk:Searching...)

Searching for the "exact phrase" "passed away" is getting false-positives, e.g. the articles Cast Away and Whitney Houston are the 3rd and 4th results. The word "passed" does not appear anywhere in those articles (including the html source code), nor in recent revisions (from any of the last month). However, those do appear to be the only false positives, in the first 200 results.

Does anyone know what is causing this anomaly? Thanks. –Quiddity (talk) 23:45, 22 May 2013 (UTC)

Searches can be affected by the displayed term in piped links. Sparkle (2012 film)#Soundtrack says "recorded by Houston before she [[Whitney Houston#Death|passed away]]". There may be a similar link to Cast Away but I haven't found it. PrimeHunter (talk) 00:34, 23 May 2013 (UTC)
The closest I can get is List of film spoofs in Mad#2000s which says in a table:
| ''Passed Away''
| ''[[Cast Away]]''
I wonder whether the search feature could have misinterpreted that as a piped link. PrimeHunter (talk) 00:43, 23 May 2013 (UTC)
That makes sense. Thanks for investigating and clearly explaining, PrimeHunter. –Quiddity (talk) 22:44, 23 May 2013 (UTC)

Geohack funny again

Geohack has gone funny again. It is showing code as well the links. Simply south...... eating shoes for just 7 years 18:15, 23 May 2013 (UTC)

Nevermind. It seems to have been corrected. Simply south...... eating shoes for just 7 years 18:34, 23 May 2013 (UTC)
I had already fixed it by the time I saw this. It was somewhat similar to this revert which I needed to do a few days earlier. The page seems to attract the attention of IP editors, few of whom make constructive edits, yet there is a discussion on the talk page which suggests that there is no need to protect it. --Redrose64 (talk) 20:02, 23 May 2013 (UTC)

Problems with relisting AfDs

I just noticed that apparently, when using the script that puts tabs at the top of the page for closing and relisting AfDs, that relisted AfDs are not always being removed from the original AfD log, and also that they're not having the 'log' link on the AfD page change to reflect the updated log. See for instance Wikipedia:Articles for deletion/SuaVay Nova - listed for AfD on the 9th, it was relisted on the 17th, but remained on the 9th's log and the 'View log' link still goes to the 9th... - The Bushranger One ping only 17:42, 18 May 2013 (UTC)

Sorry, this is my fault. If you use the closeAFD script's relist button, the action can often take 30-45 seconds to complete. In this case, I think I relisted two AfDs in the same minute, which resulted in an edit conflict when removing from the older page. LFaraone 02:53, 23 May 2013 (UTC)
Ah. Well, when I tried relisting them myself, I got the same result... - The Bushranger One ping only 18:03, 24 May 2013 (UTC)
I just relisted Wikipedia:Articles for deletion/Network Chorley (2nd nomination), and while it did properly transfer from one log to the other, the 'View log' link remained pointing to the original log, not the relisted one. - The Bushranger One ping only 18:25, 24 May 2013 (UTC)

Marquee element

Hello! I want to know how Marquee element of HTML can be used on Wikipedia. If not that particular one, how can we get the text to scroll up/down/right/left?

<marquee behavior="scroll" direction="up">This doesn't work! :( </marquee>

I don't know anything about coding. But i tried this one above and its not working. Can someone help? §§Dharmadhyaksha§§ {T/C} 07:59, 23 May 2013 (UTC)

You can't; it's a blacklisted element, and not just because it's distracting and has accessibility problems. It was a Microsoft idea, which was never part of the formal HTML standards (HTML 2.0; HTML 3.2 or HTML 4.01) and is not part of HTML5 either. --Redrose64 (talk) 11:05, 23 May 2013 (UTC)
Oh okay! Well... not that then can such effect be achieved through any other way here on Wikipedia? §§Dharmadhyaksha§§ {T/C} 11:24, 23 May 2013 (UTC)
There are ways to do such a thing, but I'm curious as to why you would want to, where you would want to, and what you expect it to look like? Technical 13 (talk) 11:43, 23 May 2013 (UTC)
I want to use this for a list, where the entries would move from bottom to top or whatever; nothing is yet fixed. You can read the whole proposal here. §§Dharmadhyaksha§§ {T/C} 12:02, 23 May 2013 (UTC)
So, my understanding is that you want a dynamic scrolling list that updates itself as new articles are added, is this correct? If so, you would be looking for a dynamic AJAX Userscript that performs an api request at set intervals and updates your list. Technical 13 (talk) 12:37, 23 May 2013 (UTC)
No! Its going to be a human being who creats a list. What i am looking for is just a dynamic scrolling effect. There is no problem with a static list. But the dynamic list is more attractive one. And now that i am proposing no specific time for updation, a dynamic list is better. §§Dharmadhyaksha§§ {T/C} 16:02, 23 May 2013 (UTC)
Marquee is not part of HTML but part of CSS3. -sarvajna (talk) 10:52, 24 May 2013 (UTC)
Dharmadhyaksha is talking about the marquee element, which was devised by Microsoft and first incorporated into Internet Explorer 2 (November 1995), and since it is invoked as <marquee attributes>...</marquee>, it is a form of HTML although it has never been part of the formal HTML standard. IE2 predates CSS by over a year, and CSS couldn't be used from HTML until HTML 4 (December 1997). CSS 3.0 (but no earlier versions) does have what it calls a "marquee module", which I have deliberately refrained from giving details for. --Redrose64 (talk) 14:03, 24 May 2013 (UTC)

Watchlist question

I just moved BiblioTech to BiblioTech (San Antonio), and marked the new page on my watchlist. However, it doesn't show up in my Watchlist. Like it doesn't exist. I've never had a problem moving files before. I wonder if something has changed in my account to make this one of those tricky things like edits for the non autopatrolled not going through until reviewed by someone else. Please let me know. — Maile (talk) 19:46, 23 May 2013 (UTC)

I have the opposite problem. Once or twice a week, an edit appears in my watchlist and I don't recognise the page at all; and checking the history of the page and its associated talk page, I've never edited either of them. I suspect that somehow, one person's "watch" request is being stored against a different user's name. --Redrose64 (talk) 20:05, 23 May 2013 (UTC)
I have twice experienced something which may be related. Quite embarrassing. See User talk:Moriori#WP:DRN and User talk:Moriori#Could you please explain. I did not make either of the problematic reverts mentioned in those items. Are someone else's edits somehow being attributed to me? — Preceding unsigned comment added by Moriori (talkcontribs) 20:48, 23 May 2013 (UTC)
Moriori, both those edits attributed to you look like accidental rollback clicks to me. I've experienced the same thing a few times, where while scrolling through my watchlist I might accidentally click the rollback button on a random edit. Usually I notice it, but there have been a few times when someone has had to pop round to my talk page to let me know, for one reason or another. The edit summaries match the default rollback edit summary, which for me is pretty conclusive evidence. Now, if you don't have either of those pages on your watchlist, then we have a whole new set of problems... Evanh2008 (talk|contribs) 20:54, 23 May 2013 (UTC)
Thank you for your response. Each time I visit my watchlist, I scroll down with the cursor on the left, deliberately, to prevent (I thought) accidentally clicking on rollback which is usually on the right, so it seems very unlikely I would accidentally do an involuntary revert. So much for the theory! This morning I see one entry in my watchlist like this:
"(diff | hist) . . Wikipedia talk:WikiProject Templates‎; 06:52 . . (+248)‎ . . ‎Patrick87 (talk | contribs | block)‎ (→‎Dealing with former needed parameters:
re) [rollback]"
so that stymies my theory about being on the right. However, I can't see why I would hit rollback instead of the diff on the line following. I guess I must have become blase, and will need to be more careful. Cheers. Moriori (talk) 21:34, 23 May 2013 (UTC)
Well, I know what you mean, because it's happened to me; once to my certain knowledge, possibly one other time although I don't recall when. I now guard against this by making sure that the watchlist can't flick up or down by one or two lines after it's finished loading. The two main culprits are:
geonotices, which always start off hidden, and expand after loading unless previously dismissed - so if a geonotice appears, I read it, bookmark any links I'm interested in and then dismiss it
watchlist notices, which always start off expanded, and then collapse if I had previously dismissed them - so if a new watchlist notice appears, I read it, click its first link so that it turns to the "visited" colour (which is green for me, because I can't tell the difference between the blue and purple shades that are the defaults around here) but I don't go for its "dismiss" link. The "visited" colour serves as a reminder that I've read it.
In summary: dismiss all geonotices but never dismiss watchlist notices, and the watchlist won't flick up or down after loading. --Redrose64 (talk) 23:14, 23 May 2013 (UTC)
As an aside, why did you move the article? Yes, there may be other BiblioTechs but in the absence of articles about them, I am not sure that a preemptive disambiguating move was necessary.--ukexpat (talk) 20:52, 23 May 2013 (UTC)
OK, Ukexpat, I'm not going to argue that point with you. But this still doesn't tell me why it isn't showing up on my Watchlist. It shows up on my "Contributions", but not Watchlist. I can make the Biblio Tech page show up, but not the one it moved to. Did someone change my user rights without telling me? Another phenomenon, perhaps related (or not) to this. I have Rollbacker rights, which work fine. I can do the regular rollback, an AGF rollback which will be noted as such in the edit summary, and a "rollback (Vandal)". What's changed on that is that I can do a vandalism rollback, but it shows in the edit summary as an ordinary rollback. I thought the edit summary was supposed to say "identified as vandalism". Any clue about that? — Maile (talk) 21:18, 23 May 2013 (UTC)
That change to the Twinkle edit summary was the result of this archived discussion. -- John of Reading (talk) 21:25, 23 May 2013 (UTC)
Thanks, John of Reading. That answers one question. Still open is my original question on why the moved file won't show up on my watchlist. — Maile (talk) 21:30, 23 May 2013 (UTC)
  • Well, it hasn't always been this way, but...the file shows up on my watch list if I edit it and save. It just wasn't showing up when I moved it. Go figure. — Maile (talk) 23:12, 23 May 2013 (UTC)
Maybe it got put on somebody else's watchlist, if my earlier suspicion is true. --Redrose64 (talk) 23:14, 23 May 2013 (UTC)
It's funny now that it's working ok again. But a good thing we don't depend on this to pay our bills. — Maile (talk) 23:16, 23 May 2013 (UTC)
For example, this edit appeared in my watchlist today. I don't recognise the name, and I can't find myself in the history of either the talk or the article. But somehow it's on my watchlist. --Redrose64 (talk) 12:24, 24 May 2013 (UTC)

Page display glitch

Wikipedia:Administrators' noticeboard/Archive248 has some content that appears in the edit buffer that's not displaying in the rendered page. If you click edit and search for "Please remove my ban" you'll see some of it. Seems to have happened here. NE Ent 03:01, 24 May 2013 (UTC)

Fixed, what a difference a closing brace can make! Graham87 05:00, 24 May 2013 (UTC)
A bit more info: The comment in the diff above add an open set of curly braces, which wasn't a problem until this message with a surplus set of closing braces was archived, then the software thought that all the text between the open braces in the first diff and the closing braces in the second diff was all part of one template parameter. I figured out where the problem was by editing the "‎Improper use of speedy deletion ..." section (which was over 400K due to the template glitch) and comparing the displayed text with the text in the edit window. I'm going to remove the unneeded closing braces now, just because I'm paranoid like that. Graham87 05:09, 24 May 2013 (UTC)
Thanks a lot! It was also making load times impossibly huge, which didn't help. :) ·Salvidrim!·  06:46, 24 May 2013 (UTC)
Here, passing many large parameters to a run-away template becomes exponentially slower, as the bar/pipes add 2 more parameters at each signature, and the parser struggles to prepare the massive 400 kb parameters, likely rescanning the earlier parameters to see if they have the same parameter name/number as the next run-away parameter gobbled into the template. -Wikid77 22:51, 24 May 2013 (UTC)
Thanks ... thought it was prob something like that. NE Ent 09:58, 24 May 2013 (UTC)

Sandboxes at the Afc

Dear Tech people:

Earlier today over 100 sandboxes, all with different users, appeared in the Afc submission list, with submission dates as much as 19 days old, although they were not there yesterday. None of them are finished articles. The reviewers have been marking them for deletion, but no one knows what has caused this. Each appears to have been submitted by the proper user. Is there some kind of technical experiment that could be changing submission dates or adding submission templates with old dates to people's sandboxes inadvertently? I am worried that people may wake up today and find their half-finished projects gone. —Anne Delong (talk) 11:46, 24 May 2013 (UTC)

Please give a link to the list you refer to, and an example page. PrimeHunter (talk) 13:42, 24 May 2013 (UTC)
See WT:WikiProject Articles for creation#Backlog just increased for details. Technical 13 (talk) 14:47, 24 May 2013 (UTC)
I don't see a link to a list there. I guess it's actually a category but I don't see a link to a category either. If you ask outsiders for help then you shouldn't make them work just to figure out which page you want help with. But it appears the insiders have worked it out. Maybe "the Afc submission list" meant Category:Pending AfC submissions (one of many categories with AfC submissions). PrimeHunter (talk) 18:41, 24 May 2013 (UTC)

Technical change in RfA procedure

 – There doesn't seem to be much point in proposing something that isn't very clear. Hence, the idea lab would be better to decide how this thing will work, or if it will at all; rather than subjecting it to supports and oppositions already. smtchahaltalk 09:17, 25 May 2013 (UTC)

All of a sudden page is messed up

Resolved
 – Thanks for fixing. -- Toshio Yamaguchi 21:12, 25 May 2013 (UTC)

In my draft page at User:Toshio Yamaguchi/Main page redesign proposal, all of a sudden the boxes are all messed up. It looked OK the last time I looked at the page yesterday. In particular, the second round-cornered box is supposed to sit below the FA box. Since I didn't make a change that could have caused this (at least not that I am aware of) I guess that a change was made somewhere else. What can be done so that it appears as intended again? The FA box is supposed to be a separate box above the box containing In the news, Did you know and On this day. -- Toshio Yamaguchi 10:59, 25 May 2013 (UTC)

Today's featured article Wikipedia:Today's featured article/May 25, 2013 has an unclosed "div". -- John of Reading (talk) 11:19, 25 May 2013 (UTC)
Fixed. Ucucha (talk) 13:19, 25 May 2013 (UTC)

Over the last couple of days, I've noticed in that the AfD template the link to the discussion page (with the phrase "this article's entry") is in red instead of the usual blue. I (and at least one other editor) assumed the link was broken, but it still works when you click on it; however, when you hover over it you see "(page does not exist)". Although it still "works", the red color is confusing. Thanks and all the best, Miniapolis 14:02, 24 May 2013 (UTC)

  • Agree the redlink is confusing and should link overall title: So, an admin should update the protected Template:Article_for_deletion/dated, to provide a stand-alone blue-link:
  • Old: '''[[Wikipedia:Articles for deletion/{{{page|{{PAGENAME}}}}}|this article's entry]]'''
  • New: '''[[Wikipedia:Articles for deletion<includeonly>/{{{page|{{PAGENAME}}}}}</includeonly>|this article's entry]]'''
By having the conditional <includeonly> tag, then the former redlink would become a valid blue-link in stand-alone mode showing the template blurb, as link "this article's entry" to be less confusing for users who are not familiar with using that template. Using <includeonly> runs within 1/2000 second and would not affect performance of the AfD template. -Wikid77 (talk) 15:10, 24 May 2013 (UTC)
See Wikipedia:Village pump (technical)/Archive 108#Link to AfD discussion in template incorrectly displaying as redlink and Wikipedia:Village pump (technical)/Archive 110#Redlink to AfD debate. --Redrose64 (talk) 15:12, 24 May 2013 (UTC)
Thanks for the help. Since the problem seems browser-dependent (forgot to mention I'm using Firefox 21.0), I'm more comfortable purging the cache than making my first edit to a protected template at this time :-). All the best, Miniapolis 15:26, 24 May 2013 (UTC)
Editing the template wouldn't help here. Wikid77 has the wrong end of the stick and is talking about a different issue. They're talking about how the link is red when viewed at Template:Article for deletion/dated, because the template hasn't really been nominated for deletion. You're talking about a red link showing when the template is used on an article that really is nominated for deletion. In your case, purging the article is all we can do at present. – PartTimeGnome (talk | contribs) 22:44, 26 May 2013 (UTC)

List of national anthems out of order

What happened?

What happened to the List of national anthems? Screenshot is taken in IE with Monobook; I've reloaded the page multiple times without noticing any differences. Nyttend (talk) 22:23, 25 May 2013 (UTC)

Hmm, looks OK for me in Firefox 21 and IE 10. Maybe a caching problem on your side? The only glitch I noticed are the empty source fields for many anthems, which should probably contain at least a &nbsp; to not produce empty cells. --Patrick87 (talk) 22:40, 25 May 2013 (UTC)
Looks fine to me (Monobook on Safari on OSX). Maybe clear out your cache? Ignatzmicetalk 22:42, 25 May 2013 (UTC)
It's fine for me (Firefox 21 under Windows XP in Monobook skin). However, it does take a very long time to load, so your setup may have a memory issue. Regarding the last (Source) column: it's not necessary to put &nbsp; into those, just make sure that there is a cell-start marker (single pipe on a line of its own, or double pipe at the end of the cell for the audio file) for that column on every row without a source. --Redrose64 (talk) 23:08, 25 May 2013 (UTC)
OK, thanks for the information. I'm not too familiar with Wikitables (I never now were to put styles, how many pipe characters I need, etc. Actually I'd prefer to do them in pure HTML if I could . Either way I already changed the tables before, but I suppose a &nbsp; doesn't harm either. --Patrick87 (talk) 23:18, 25 May 2013 (UTC)
There are several tools available to convert HTML to wiki syntax, see Wikipedia:Tools/Editing tools#From HTML. Thryduulf (talk) 17:06, 26 May 2013 (UTC)

Problem deleting redirect. Developer action needed?

Per Wikipedia:Redirects for discussion/Log/2013 May 18#ƀ, the redirect at ƀ (note not the uppercase Ƀ) needs deleting. Neither I nor the closing user (JohnCD) can actually manage to do it though as every time the autocapitalisation kicks in and asks you whether you want to delete the uppercase page, even when manually specifying ƀ in the URL. I don't know whether there is some way to directly access the lowercase version via the bot API or something, but if not I guess then we'll need to ask a developer to directly tweak the database? Thryduulf (talk) 17:01, 26 May 2013 (UTC)

There is no redirect; what you see is MediaWiki auto-coverting the lowercase letter to uppercase. Notice there is no "Redirected from..." mesage when you go to http://en.wikipedia.org/wiki/ƀ, and it is also not listed on Special:DoubleRedirects. Pretty much all of these articles (see navbox) exhibit this behaviour. Edokter (talk) — 17:21, 26 May 2013 (UTC)
From this page, for the lower-case ƀ, clicking any of "Edit" or "View history" or "Delete" gets you to the corresponding page for upper-case Ƀ. Even odder, from the previous version of ƀ, "View history" and "Delete" still get the upper-case version, but "Edit" actually gets the lowercase one. JohnCD (talk) 17:32, 26 May 2013 (UTC)
http://en.wikipedia.org/w/index.php?title=%C6%80&curid=7046002&action=history is a url to its page history. If a query url contains a revision id then the title is ignored so http://en.wikipedia.org/w/index.php?title=anything&curid=7046002&action=history gives the same result. It appears that MediaWiki currently, but not always in the past, treats ƀ as a lower case Ƀ when the first character in a pagename is automatically capitalized. It's also conceivable that something depends on the server like the situation ɱ (LATIN SMALL LETTER M WITH HOOK) versus Ɱ (LATIN CAPITAL LETTER M WITH HOOK) at Wikipedia:Village pump (technical)/Archive 105#Link in history says user does not exist. PrimeHunter (talk) 17:53, 26 May 2013 (UTC)
What happens if you try this delete link (admins only)? I can't try it myself, not being an admin. – PartTimeGnome (talk | contribs) 20:57, 26 May 2013 (UTC)
It originally sends you to the deletion dialog for ƀ, then as soon as you click "delete this page", MediaWiki shows you the deletion dialog for Ƀ. No deletion actually occurs. Titoxd(?!? - cool stuff) 21:03, 26 May 2013 (UTC)
 Done. I looked up the page id with ?action=info, and then used that in a request through Special:ApiSandbox. Legoktm (talk) 21:12, 26 May 2013 (UTC)

Autocorrecting Edit-conflicts as Edit-merges

Related: #A real edit conflict.
Related: #Report days since Edit-conflicts still not fixed.

We need to focus on having an Edit-merge dialog to autocorrect for simple edit-conflicts. I wrote essay "wp:Avoiding edit-conflicts" to explain how to proofread, then simply re-edit, and tediously copy/paste before SAVE, to reduce edit-conflicts, but some autocorrection could be done as well. For years, we have wanted the edit-conflicts to be fixed, especially for simple cases, such as a new thread appended at bottom, inserting a short reply, or changing a few words in the non-edited paragraphs. Because any intervening change can profoundly alter the meaning of the edit-conflict text (such as someone inserting the word "not"), then the Edit-merge dialog would be yet another edit-preview requiring active approval, but with new text retro-inserted into the latest, prior revision of a page, for further proofreading. Then, the editor (handling the Edit-merge) decides whether to hit SAVE or rewrite the edit-merged text, as perhaps to respond otherwise to the recent interleaved changes. What is the status of developer updates to directly auto-correct and merge the edit-conflict problems? Does anyone think retro-inserting the reply text, at the same relative points would not work well enough in most cases? This has been a high-priority problem, especially when working on new hot-topic articles, where inserting a short phrase+footnote often gets an edit-conflict for some other erstwhile modified paragraph, even within a section-edit change. -Wikid77 (talk) 05:19, 17 May 2013 (UTC)

  • Edit-merge works for separate portions but 2-reply conflict needs FIFO consensus: Extensive auto-correction for many edit-conflicts has existed since 2004, when re-combining separate parts of a page, such as the 1st editor changes the infobox parameters, while 2nd editor changes a later paragraph, and the 2nd editor's paragraph is inserted with the 1st editor's infobox. The next fix would be for 2 replies added after the same line, in a talk-page, or a list (etc.). However, the editor community needs to reach a consensus, so the developers would have a resolution, to append a 2nd reply, after the 1st reply, at the same line number, which is currently treated as "edit-conflict" and extremely common in fast-moving talk-pages. I suggest to use FIFO order (first-in, first-out), so the 1st reply takes precedence over the 2nd reply, to be inserted after the 1st. The developers have already finished "90%" of the bigger, complex Edit-merge operations, and what is left is to decide the community's choice as to which order to append two replies at the same line number, such as FIFO order. Perhaps we need an RfC to decide that issue. -Wikid77 (talk) 10:54, 21 May 2013 (UTC)
    Too much editor discretion is involved in merging that type of conflict for it to be automated. One might choose to place the 2nd comment after the 1st, to maintain chronological order. However, if the 2nd comment is in reply to something particular, while the 1st is a reply to the whole thread, the author of the 2nd comment might choose to place it before the 1st. The 2nd commenter might choose to abort their edit if the 1st commenter said pretty much the same thing they did. They might also want to change the indentation of their comment or even the content, to be more consistent with the first editor.
    Basically, the 2nd commenter needs to answer the question "what would you have done if the 1st comment was there when you started to comment?". The software can't answer that without additional input from the 2nd commenter.
    Also consider that the same edit conflict resolution algorithm is used on articles – if two people try to insert a paragraph at the same position in an article, it needs a human to arrange and/or re-edit the text so that it flows smoothly from one paragraph to the next.
    Your current concerns seem mainly about talk pages, so the developers probably won't have much interest in changing this – they want to replace wiki-style talk pages with Flow. Since each comment is kept separately in Flow, it isn't possible for one comment to conflict with another (the same was true of LiquidThreads, but the WMF killed that project).
    I think the main development work needed for edit conflict handling is to make the UI friendlier and easier to use. Some examples: a) Only show the sections of the page that are in conflict, rather than the full wikitext of the page. b) If an edit affected multiple parts of the page, automatically merge those parts that did not conflict rather than forcing the user to manually merge all of it. c) A single edit box with SVN-style conflict markers. (The wiki software could reject attempts to save if the conflict markers weren't removed from the text. This would also make it harder for someone to copy the text of their edit over the current text without merging the changes.) – PartTimeGnome (talk | contribs) 22:36, 23 May 2013 (UTC)
  • Stopping the edit-conflict to give 2nd user power to choose is illusion: I know it might seem there are many decisions for the 2nd editor's reply, as to rethink the placement, to rethink the wording, or to consider the 1st editor's reply was enough, but that level of control is just an "illusion of control" and the 1st editor (or anyone) could re-edit to shift comments, or hat-hide sections, to overpower the careful edit-conflict resolution of a 2nd editor. The same would happen in articles, when the 2nd editor added a line or sentence, at the same point, where the 1st editor's text was added. In a general sense, the edit-conflict halt is a heightened case of multiple people working on the same page, but focused on the same consecutive lines. The general problem is:
  • Edition-confliction:  Some other people might change what you wrote,
    please reconsider editing this page next month, next year or never again.
However, the fatal edit-conflicts at consecutive lines are an interesting narrow, rabid focus on 2 editors changing nearby lines, as if it were an end-of-the-world crisis decision, "Aaarrgghh! OMG, another editor inserted a line at that same point, can u imagine? Oh no, Oh no, what to do? what to do? how could life go on if your text was inserted after the 1st editor's text rather than before it, OMG, call for help, sound the alarm, OMG, OMG, Oh-My-friggin-GAAWWDD!"  I had not realized that edit-conflicts were actually such an exaggeration of the critical impending dangers of 2 editors inserting text at the same line, as yet another DramaQueenapedia blowup over what should be just, "2nd editor's text is inserted following 1st editor's text" (simple as that). However, I can understand how the exaggerated fear of consecutive lines has allowed the edit-conflicts to remain all these years, but it is past time to just simply combine the edits of the 2 editors, where the 2nd editor follows the 1st text. When that is fixed for talk-pages, then the same fix would apply in articles, where the 2nd editor's new sentence would append after the 1st editor's text inserted, or a 3rd editor might decide to rearrange the text added by both editors. -Wikid77 (talk) 01:16, 24 May 2013 (UTC)
The ability of others to later edit what I write has nothing to do with edit conflict resolution. If someone changes what I've written, my original comment can be found in the page history, whereas an edit conflict leaves no trace in history. Editing comments by other users is discouraged in any case. People and bots who edit disruptively can be blocked by an admin; a misbehaving conflict resolution algorithm would need a developer to fix it.
I make a point of previewing my edits and re-editing until I am happy with them. When I get an edit conflict on a talk page I'll typically re-edit my comment, if only to change the indentation. I don't want to re-edit to fix damage by a braindead conflict resolution algorithm that thinks it knows better than me. Automatic conflict resolution must get it right without guessing at what the editor wants. I don't want badly merged edits saved under my username. I'd like to avoid embarrassments like this. – PartTimeGnome (talk | contribs) 21:53, 26 May 2013 (UTC)
Sometimes an edit is lost when there is no apparent edit conflict, such as this edit from two days ago - they're in different sections. --Redrose64 (talk) 22:37, 26 May 2013 (UTC)
  • Prior bug overwrites previous revision within 2 minutes: Now we see 3 major problems: fix multi-replies, fix multi "new section" and fix overwrite of recent edit. The problem of removing the prior edit (dif-557), to wp:PUMPTECH page, seems to follow a pattern where an edit-conflict should have been edit-merged with previous revision (within 2 minutes earlier) but was incorrectly "auto-removed" when storing the next edit. Although I know we should not talk much about non-WMF wikis here (as red herrings), I found reports from July 2012 of other MediaWiki-based wikis with similar overwrites within 2-minute interval, and I concluded perhaps it was not a local developer-related bug but perhaps inherent in recent MediaWiki software. That's a lot of "perhaps" but it is another good reason to fix simple edit-conflicts, as a chance to rework edit-conflict algorithms which have prior bugs, and also auto-append a new "==header==" conflict-edited into the end section of an article/talk-page. Again, developers have asked people to scope the consensus to work on edit-conflict problems, else not a priority for them. As a tangent, I will note sometimes it is easier to extend software, with new algorithms, rather than "fix a prior bug" directly, because the new algorithm might bypass the bug or else handle more cases where the bug fix would have been hindered by the older algorithm. So then here is the crux: to resolve 2 additions/deletions at same line number, then developers need decision, such as FIFO (first-in, first-out) where 1st editor appends at line, but 2nd editor appends after 1st, as the automatic (rapid) way to resolve the common 2-replies, or 2-additions, edit-conflict. Meanwhile, there have also been apparent overwrites of 2 "new section" appendages within minutes of each other. Sorry to ramble but we have 3 major problems: fix multi-replies, fix multi "new section" and fix overwrite of recent edit.-Wikid77 13:54, 27 May 2013 (UTC)
  • Need read-lock to avoid "new section" edit-conflict overwrite: While not knowing how "new section" has been implemented, I think we need to ensure this option does a read-lock of the latest revision, so that 2 concurrent users running "new section" do not both read the same revision and merely append a different new end-section. This is a classic "test-and-set" operation, where the final revision must be read-locked, to insert the next new-section text, write and then unlock the page. If not properly read-locked then both users will read the same prior revision and each append a different end-section, to explain the current overwrite of "new section" texts within 2 minutes. But how long before a read-lock should timeout, considering the 60-second wp:Wikimedia Foundation error? -Wikid77 14:38, 27 May 2013 (UTC)

DISPLAYTITLE is not working

RESOLVED: With method & documented. -Wikid77 04:06, 28 May 2013 (UTC)

I put a DISPLAYTITLE template at the top of Kalai's 3^d conjecture to make it display as Kalai's 3d conjecture. Obviously to leave it as Kalai's 3^d conjecture would be barbaric. But the template isn't working; the title still appears as Kalai's 3^d conjecture. What's wrong? Michael Hardy (talk) 18:33, 20 May 2013 (UTC)

That's probably because DISPLAYTITLE only works with titles that are still the same as the original when layout is removed. Try deleting the ^ from the title. Ucucha (talk) 18:35, 20 May 2013 (UTC)
I reverted your move with reason "3d is wrong. 3^d means something else. Categories, search pages and many other places will display the actual pagename and not the DISPLAYTITLE".[3] I then fixed DISPLAYTITLE to display as 3d by hiding ^ with "display:none".[4] Diffs don't display the DISPLAYTITLE but the revision [5] does. PrimeHunter (talk) 22:42, 20 May 2013 (UTC)
  • Updated Template:DISPLAYTITLE doc for superscript/subscript: This topic is an excellent issue for the documentation pages, so I have expanded the examples to include superscripts and subscripts. Although magic word {DISPLAYTITLE:} is recommended, the template doc page also shows some examples, and I added title "E sub 0" as "E0" as another example:
"E sub 0" as:   E<span style="display:none"> sub </span ><sub>0</sub>
(redone later as):
"E sub 0" as:   E<span style="position:absolute; top: -9999px"> sub </span ><sub>0</sub>
So, "Kalai's 3^d conjecture" is the example now in Template:DISPLAYTITLE for superscripts. In general, many solutions here can be used to update the documentation or help-pages which are read 500x per month (or 540 pageviews for {DISPLAYTITLE} in April). -Wikid77 13:43, 21 May, 04:06, 28 May 2013 (UTC)
I have found that none of five tested browsers include the non-displayed ^ when copy-pasting 3^d. This goes against WP:DISPLAYTITLE which says: "Under the present software configuration, only limited modifications can be made: the displayed title must still resolve to the true name of the page (i.e. if the displayed title is copied and pasted into a wikilink, the link should point to the original page)." bugzilla:26547 suggested to ignore "display:none" in DISPLAYTITLE. Copy-pasting the displayed title of Kalai's 3^d conjecture gives Kalai's 3d conjecture which at least redirects to the right article, but it will look bad if people make a copy-pasted link saying Kalai's 3d conjecture in other articles. 3d and 3^d have completely different meanings. Should we avoid using "display:none"? Is there a reasonable way to write a copy-pastable ^ in a way readers usually don't notice? A tiny font in white is accepted by DISPLAYTITLE but Kalai's 3<span style="color:white; font-size:1%;">^</span><sup>''d''</sup> conjecture to produce "Kalai's 3^d conjecture" seems like an ugly hack. PrimeHunter (talk) 14:59, 21 May 2013 (UTC)
  • For 10 years "display:none" hid copy/paste text in IE browsers: The problem is with the primitive new browsers, so tell people, "Copy the title in IE then paste into their browser to see it", or perhaps some other "display:xxx" setting could be used first, as both together "display:xxx; display:none" where IE would ignore the "xxx" but still process "display:none" and work fine. Anyway, we will find something that works, and don't worry about "ugly hack" because most all computers today are ugly hacks, where most people can no longer tell the difference. I mean even Google cannot directly search for "2+2=4" because it does not know it is an equation, but Google can auto-respell about 500 million words, yet remains clueless about "=" equal sign, so tell me that is not an ugly hack to ignore beginner math (arithmetic) when searching text. The mind boggles, as with cars which auto-lock the doors if started with door open, driver steps out to get package, and the door autolocks with engine running. If $multi-billion corporations can provide such crapnology, for years, then I think we can use "font-size:1%" if needed. Anyway, thanks for noting yet another problem with the new browsers. -Wikid77 06:43, 22 May 2013 (UTC)
    • That's what display: none; is intended to do. Use position: absolute; top: -9999px; to have the text display, but offscreen. That said, I suppose $wgRestrictDisplayTitle is set to true for a reason, and it allowing display: none; is definitely a bu – this setting should also probably strip (almost) all CSS from the displaytitle values. Matma Rex talk 08:02, 22 May 2013 (UTC)
    • I have just submitted a MediaWiki code change for review that would disallow display: none; and several similar values which break $wgRestrictDisplayTitle: [6]. If you were using this anywhere else, please stop, since (assuming the change is merged) it will soon stop working. Matma Rex talk 09:04, 22 May 2013 (UTC)
The display:none; property "causes an element to not appear in the formatting structure". If the element is not in the formatting structure, any text which it would have contained is not present in the rendered page, so is not copypasteable. If IE permitted such text to be copypasted, that is simply another deviation from the standard by Microsoft. --Redrose64 (talk) 10:34, 22 May 2013 (UTC)
I've been keeping an (albeit intermittent) eye on dubious uses of DISPLAYTITLE for a few years now. The tool I've been using to do so is available on the Toolserver for anyone else who'd like to assist with the task - http://toolserver.org/~tb/ODT. - TB (talk) 08:43, 22 May 2013 (UTC)
You might want to look at the gerrit change linked above and see if I missed something else that shouldn't be allowed :) Thanks. Matma Rex talk 09:04, 22 May 2013 (UTC)
Until recently, Firefox would copy display:none; text as well. This was often an issue on the Wikimedia error message page, where users would copy the entire page contents, rather than just the displayed text. (Also, the abuse potential of the enhanced-but-restricted DISPLAYTITLE goes beyond a few missing characters.) --Splarka (rant) 08:16, 23 May 2013 (UTC)
User:Wikid77's argument about not worrying about ugly hacks is a classic WP:OTHERSTUFFEXISTS argument. The existence of other ugly hacks is no reason to tolerate or encourage further hacks. Be careful about increasing our technical debt.
Also, missing features in Google can hardly be called ugly hacks – it is functioning as designed. Because it doesn't do what you want doesn't make it a hack – treating equations differently from other search terms would be more of a hack. Having said that, Google does give special treatment to "2+2=". – PartTimeGnome (talk | contribs) 14:28, 26 May 2013 (UTC)
User:PartTimeGnome has claimed "functioning as designed" can hardly be called "ugly hacks" which follows how? The term "design flaw" does not preclude ugly hacks in operation. Plus "treating equations differently" is exactly what Google has been doing, where a search for "2+2=4" failed, when Google supported "2+2 equals 4". Please note, "What part of comma or semicolon does '=' represent?" None, the equals sign is a symbol, not a form of comma separator to be ignored. So, for Google to recognize "$500" as "500 dollars" but ignore '=' as not being "equals" in text is an ugly hack, and has been for decades. And then demanding Wikipedia to never allow ugly hacks is not an issue of WP:OTHERSTUFFEXISTS, but rather a classic "double standard" argument. Instead, this is a "wiki" where initial hack text can be improved, over time, as we did during this week, to improve display of superscripts/subscripts in titles and allow copy/paste of titles on any browser, all part of excellent progress. Done. -Wikid77 04:06, 28 May 2013 (UTC)
Fair point that a design can be just as much of a hack as code. I've also struck out my "be careful" comment, as it goes against the wiki-way of being bold. You're right that things start as hacks on wikis and are later improved. That improvement only happens because people care enough to make improvements. Rather than saying "don't worry about ugly hack", say "it's an ugly hack; we can improve it".
I'm still unsure how you define the absence of a feature as a hack. A hack is something done poorly; something not done at all is not a hack. The whole thing of matching synonyms of the words and symbols in a search is a hack, though – it gives the appearance of intelligence where none exists, and Google can never know about every synonym someone might want to use.
In any case, we are now most definitely off-topic. Gripes about Google don't have much to do with Wikipedia... – PartTimeGnome (talk | contribs) 21:25, 28 May 2013 (UTC)
  • Confirmed text positioned off-screen can copy/paste in new browsers: To continue the sophisticated formatting of superscript/subscript titles in {DISPLAYTITLE}, I think hiding the "sub" or caret "^" text is fine using span-tag attributes "<span style="position: absolute; top: -9999px;">^</span>" as a browser-independent technique. The prior method using "display:none" does not work to hide copy/paste text in newer versions of Firefox, although it worked for over 10 years in older versions of MSIE. The wiki world is ready for more sophisticated titles, such as "E0=mc2" to explain the level of energy (E) at velocity zero (0). -Wikid77 (talk) 22:17, 24 May 2013 (UTC)

Tech news — 2013, week 21

Tech news prepared by tech ambassadors and posted by Global message deliveryContributeTranslateGet helpGive feedbackUnsubscribe • 19:10, 20 May 2013 (UTC)

Smaller watchlist arrows

Usage of arrows in the interface of Vector and MediaWiki in general.

Is this the source of the apparently smaller "expand changes" arrows in watchlists? Is there some rationale for making them smaller and harder to click than ever before? Is there some CSS I can use to force them back to what they were before? Elizium23 (talk) 20:38, 20 May 2013 (UTC)

Yes, this was changed in this deployment. The clickable area of the arrows is not smaller; only the image has changed to resemble the icon used throughout the Vector skin and the new editing toolbar interface. (For any confused readers: this only applies to the "enhanced" watchlist and recentchanges you can enable in preferences.) Matma Rex talk 20:52, 20 May 2013 (UTC)
OK, so the clickable area is the same. I don't know about other users, but personally, I attempt to actually touch the control with the pointer before I click on it, so the reduction in graphic size does effectively reduce the clickable area for my own use pattern. Got some CSS to repair it? Elizium23 (talk) 22:37, 20 May 2013 (UTC)
I first noticed this change with the #Something's wrong again fix above which makes me assume that this was part of some kind of fallback fix... Matma Rex, you're telling me this is unrelated? I'm not sure I like it myself... Technical 13 (talk) 23:18, 20 May 2013 (UTC)
Yep, it's entirely unrelated. The icon is already used throughout the interface, and this change was simply done for consistency – see the screenshot on the right (it's from the Vector skin, but also applies for the other ones). I suppose it could be possible to come up with some custom CSS, but it would be quite an ugly hack. Matma Rex talk 21:11, 21 May 2013 (UTC)
The new arrows are too small to reasonably expand them on my brand new Samsung Galaxy phone. Technical 13 (talk) 19:43, 23 May 2013 (UTC)
Yet another uneeded change that wasn't asked for and doens't benefit the ones doing the actual work. I never used to misclick the wrong arrow for an article but it seems to be pretty common now. BTW, I don't really like the vector skin eithe so making these arrows match the vector skin is not an improvement. It would be nice if the developers could work on some of the projects we have been begging for over the years rather than practice their craft on non problems like this. Kumioko (talk) 19:50, 23 May 2013 (UTC)
That change is an improvement for me (I am a Wikipedia editor as well – thankfully not on this one), so I have implemented it, and it has been approved. Please feel free to solve the software issues you are personally having yourself, as that's precisely what I am doing – or possibly pay someone to. Clearly they are nowhere near as hard-pressing as you seem to believe if nobody has bothered to fix them "over the years". Matma Rex talk 18:35, 27 May 2013 (UTC)

URI schemes

I don't see that the new URI schemes link:

--  Gadget850 talk 20:08, 21 May 2013 (UTC)

Re geo: see Template talk:GeoTemplate#Mobile/Future Standard for Location and bugzilla:48688. --Redrose64 (talk) 20:48, 21 May 2013 (UTC)
I think this change is not deployed yet; it will be included in the next deployment, per the roadmap. Matma Rex talk 20:55, 21 May 2013 (UTC)
It isn't listed on the 1.22/wmf4 changelog, so I'm guessing this is actually in 1.22/wmf5. --  Gadget850 talk 12:06, 22 May 2013 (UTC)

Watch-listing and categories

If and editor wishes to follow the information being added to or subtracted from an article that he/she cares about, he/she can add that article to his/her watchlists and track the changes ... but as far as I know there is nothing similar for categorization. There is no way to know when an article has been added or removed from a category we care about. Is there any way to implement some sort of category watchlist? Blueboar (talk) 01:24, 24 May 2013 (UTC)

This would be very useful, if it is feasible. – Philosopher Let us reason together. 01:32, 24 May 2013 (UTC)
Especially useful for some maintenance categories. GoingBatty (talk) 02:49, 24 May 2013 (UTC)
There is an external tool for that: User:Svick/CW. — HHHIPPO 06:33, 24 May 2013 (UTC)
Thanks HHIPPO... that is good to know. Any way to make it an internal tool? Blueboar (talk) 11:50, 24 May 2013 (UTC)
this is a very old bug in bugzilla (7148). apparently, implementing this functionality is far from trivial. peace - קיפודנחש (aka kipod) (talk) 15:25, 24 May 2013 (UTC)
I wonder if one could use something like Extension:CategoryWatch, but with notifications instead of e-mails. On the other hand, to do it properly the feature should be integrated in the watchlist, which would need modified or added database tables. Indeed, far from trivial. — HHHIPPO 17:59, 25 May 2013 (UTC)
we could lobby to include this extension on wikimedia wikis, but i suspect the reason why this was not done already is not because nobody noticed this extension exists... i haven't read/reviewed the extension code, but my guess is that either the code itself does not pass muster, or that it was judged to be too expensive from performance point of view (or both). i looked into it some time ago, and as far as i remember, the functionality that the extension provides is not _exactly_ the desired functionality, but it comes pretty close.
some time ago i suggested this as a "mediawiki google summer of code (aka gsoc)" suggested project, but it was deemed to be a little more than a reasonable gsoc project, and it was practically shot down (btw, this is briefly discussed in the linked bugzilla bug). peace -קיפודנחש (aka kipod) (talk) 19:48, 25 May 2013 (UTC)
Indeed, we don't want to use the extension as is, since it's only notifying by e-mail as far as I can see. But it's a nice mechanism to catch categorization changes, which could then be stored somewhere else. I guess a good place would be the recentchanges table, then they could show up both in watchlists and in related changes. But again, that's changes to the mediawiki core, not just some added userscript. — HHHIPPO 06:44, 27 May 2013 (UTC)
A related feature that would be useful would be a history of additions and removals from a category (including categories you haven't watchlisted). – PartTimeGnome (talk | contribs) 22:21, 26 May 2013 (UTC)
To some extent that would work when using the recentchanges table (either through recent changes linked or a new special page), but only for recent changes. Otherwise one would need something like a revisions table for categorylinks, but that's yet another big step. — HHHIPPO 06:44, 27 May 2013 (UTC)

Regression of BLP editintro

Hi all; some of you (esp. First Light, Davidgothberg, TheDJ) may remember this problem concerning non-display of {{BLP editintro}} when editing a section. The problem was resolved; but I have just noticed that the old behaviour has returned: {{BLP editintro}} is only displayed when editing the whole page, not when editing a section. I've looked at recent changes in MediaWiki:Common.js but I've had to go back more than five months to find anything that might be relevant. Could it be this edit? What is the significance of a triple-equals in a test like

if ( cats[i].title === 'Category:Living people' || cats[i].title === 'Category:Possibly living people' ) {

and how does it differ from the double-equals that I'm familiar with in C? --Redrose64 (talk) 13:23, 25 May 2013 (UTC)

 Fixed Was broken due to the recent rename of the editsection class. diffTheDJ (talkcontribs) 13:34, 25 May 2013 (UTC)
To answer your question:
  • == does type coercion, so "1" == 1 == 1.0
  • === does "real" equality testing, so "1" !== 1 and 1 === 1.
LFaraone 13:15, 27 May 2013 (UTC)

Coordinates of Italian localities

I see that the coordinates of Bellagio (Italian region) are added in the template but do not show up. This is not the only case, see, for example, Barga. On the other hand, in Pisa the coordinates do show up, though they are added in the same way. Anybody could help? Thanks in advance.--Ymblanter (talk) 21:34, 26 May 2013 (UTC)

The coordinates show in the infobox in all cases (under the map). They aren't showing at the top right of the page in the Bellagio or Barga articles, however. You need to use the coordinates_display = title infobox parameter to make the coordinate show at the top right. – PartTimeGnome (talk | contribs) 22:03, 26 May 2013 (UTC)
Yes, like this. --Redrose64 (talk) 22:28, 26 May 2013 (UTC)
Thanks for answers, I had the coordinates in the top right corner in mind, indeed.--Ymblanter (talk) 15:03, 27 May 2013 (UTC)

Gadgets

All the gadgets have disappeared. This happened within the last two minutes - I noticed because MediaWiki:Gadget-OldDiff.css was no longer being applied to diffs. --Redrose64 (talk) 18:34, 27 May 2013 (UTC)

They're back now, panic over --Redrose64 (talk) 18:35, 27 May 2013 (UTC)
Really? Twinkle went and hasn't come back for me... Jared Preston (talk) 18:38, 27 May 2013 (UTC)
Ah, and after having posted that, now it's back. Oh well! Jared Preston (talk) 18:39, 27 May 2013 (UTC)
When I noticed that MediaWiki:Gadget-OldDiff.css was no longer active, I tried to go to Preferences → Gadgets but the tab wasn't there. It soon returned, and with it, OldDiff and MediaWiki:Gadget-edittop.js. --Redrose64 (talk) 18:42, 27 May 2013 (UTC)
  • Perhaps Gadgets interface redone as part of today's MediaWiki upgrade: Recall how "27 May 2013" was a planned upgrade for MediaWiki software (following the 20 May 2013) upgrade, which (re-)fixes the Gadgets interface today, so also beware other problems, especially hinted, below, in "#Tech news: 2013-22". If the developers keep announcing scheduled upgrades, such as on Mondays, then we will know to expect "everything" to fail on those days, and react accordingly, such as to edit on other-language wikipedias until they get upgraded or such. But remember all this upgrade commotion does not write the articles which have been missing for over 10 years, so try to focus on that (as well). -Wikid77 (talk) 21:23, 27 May 2013 (UTC)

Hi. I was wondering if something could somehow make a list of the top say 100 most visited articles on Denmark by page views and structure them by current assessment stub/start/B class etc into a structured list so I, Ipigott and the others can try to make them a priority for expansion? It would be very useful to us, can somebody do it?♦ Dr. ☠ Blofeld 21:19, 27 May 2013 (UTC)

Do you mean something like Wikipedia:WikiProject Denmark/Popular pages? Killiondude (talk) 21:23, 27 May 2013 (UTC)

Exactly that, thanks for finding it!!♦ Dr. ☠ Blofeld 21:31, 27 May 2013 (UTC)