Wikipedia:Village pump (technical)/Archive 112

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217

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:

• hello
• this page doesn't exist
• goodbye

This script adds a link to the sidebar ("Remove red links"). When you click this link, the list will read:

• hello
• goodbye

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 (talk • contribs) 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 decker^talk 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)

How does MediaWiki know a redlink is a redlink?

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 (talk • contribs) 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}} → 6959

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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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)

Template:Factiva

{{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).

Odd link not clickable

Tracked in Phabricator
Task T50725

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 (talk • contribs) 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 (talk • contribs) 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 decker^talk 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? --Nathan2055^{talk - 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:   Voilà! A B C D Ignatzmice•talk 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 (talk • contribs) 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.wiki.x.io"). The drop-down menu would be configured on a per-user basis to list other wikis (e.g., "meta.wikimedia.org" and "test.wiki.x.io").

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 (talk • contribs) 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

Moved from Wikipedia talk:Village pump (technical) § Sandboxes at the Afc

 – Redrose64 (talk) 15:19, 24 May 2013 (UTC)

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

Moved to Wikipedia:Village pump (idea lab) § 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. smtchahal^talk 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)

Template:Article for deletion/dated discussion-page link is red

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   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? Ignatzmice•talk 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   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.wiki.x.io/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.wiki.x.io/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.wiki.x.io/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)

• Archived subthread to re-focus on current issues: To reduce clutter here, I have archived the subthread which someone moved here from a tangent topic, now in: "/Archive_112#Report days since Edit-conflicts still not fixed". -Wikid77 14:38, 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 3^d 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 3^d 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 "E₀" 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 "E₀=mc²" to explain the level of energy (E) at velocity zero (0). -Wikid77 (talk) 22:17, 24 May 2013 (UTC)

Tech news — 2013, week 21

Latest Tech news from the Wikimedia technical community. Please inform other users about these changes.

Recent software changes

(Not all changes will affect you.)

• The latest version of MediaWiki (version 1.22/wmf4) was added to non-Wikipedia wikis on May 13, and to the English Wikipedia (with a Wikidata software update) on May 20. It will be updated on all other Wikipedia sites on May 22. [7] [8]
• A software update will perhaps result in temporary issues with images. Please report any problems you notice. [9]
• MediaWiki recognizes links in twelve new schemes. Users can now link to SSH, XMPP and Bitcoin directly from wikicode. [10]
• VisualEditor was added to all content namespaces on mediawiki.org on May 20. [11]
• A new extension ("TemplateData") was added to all Wikipedia sites on May 20. It will allow a future version of VisualEditor to edit templates. [12]
• New sites: Greek Wikivoyage and Venetian Wiktionary joined the Wikimedia family last week; the total number of project wikis is now 794. [13] [14]
• The logo of 18 Wikipedias was changed to version 2.0 in a third group of updates. [15]
• The UploadWizard on Commons now shows links to the old upload form in 55 languages (bug 33513). [16]

Future software changes

• The next version of MediaWiki (version 1.22/wmf5) will be added to Wikimedia sites starting on May 27. [17]
• An updated version of Notifications, with new features and fewer bugs, will be added to the English Wikipedia on May 23. [18]
• The final version of the "single user login" (which allows people to use the same username on different Wikimedia wikis) is moved to August 2013. The software will automatically rename some usernames. [19]
• A new discussion system for MediaWiki, called "Flow", is under development. Wikimedia designers need your help to inform other users, test the prototype and discuss the interface. [20].
• The Wikimedia Foundation is hiring people to act as links between software developers and users for VisualEditor. [21]

Tech news prepared by tech ambassadors and posted by Global message delivery • Contribute • Translate • Get help • Give feedback • Unsubscribe • 19:10, 20 May 2013 (UTC)

•  Comment: This is partly a follow-up to Wikipedia:Village pump (proposals)#Developer's Noticeboard. Feedback is greatly appreciated. guillom 19:26, 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:

• ftps://example.org/
• urn:isbn:0451450523
• geo:37.786971,-122.399677

--  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

Tracked in Phabricator
Task T9148

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. diff —TheDJ (talk • contribs) 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)
  • No, that wouldn't even make any sense (referring to the bold part). It's probably the known, but nasty, T39228. Matma Rex talk 21:43, 27 May 2013 (UTC)

Most popular Denmark articles

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)

Tech news: 2013-22

Latest tech news from the Wikimedia technical community. Please inform other users about these changes.

Recent software changes

(Not all changes will affect you.)

• The Translate extension and Universal Language Selector were enabled on Wikimedia Commons on May 20. Commons users can now easily change languages, and translate pages with a friendly interface. [22]
• The Notifications feature, active on the English Wikipedia, now supports local blacklists and whitelists. It is possible to hide users (for example certain bots) from all notifications on the wiki. Also, e-mail notifications are now grouped. [23] [24]
• The first stable release of MediaWiki 1.21 for sites outside Wikimedia was published on May 25. [25]
• The tool storing information about languages (CLDR) was updated to the latest version (23.1). [26]
• Due to a software issue, users couldn't enable or disable Gadgets. The issue is now fixed.

Future software changes

• MediaWiki will stop supporting XHTML 1.0 and HTML versions lower than version 5. HTML5 will now be the default language for pages created by the software. [27] [28]
• The software will check if all uploaded files are secure and match their type. [29]
• The Wikimedia Commons Android app will come out of the beta phase on its next release. [30]
• Account creation by manual log-in will now be recorded in the account creation log (bug 42434). [31]
• Links to file description pages will again be accessible directly from within videos (bug 43747). [32]
• The software behind recent changes patrolling was re-written; the change fixes issues related to patrolling new pages, among other things. [33]
• During a meeting, developers agreed on rules about making big changes to the software. [34]
• There is now a category to list pages with invalid music code. [35]

Tech news prepared by tech ambassadors and posted by Global message delivery • Contribute • Translate • Get help • Give feedback • Unsubscribe.

BTW. rules is a big word for the discussion that we had. It is an agreement that we (both funded and volunteer devs) need some process in order to make the big changes to the architecture of the code that we all think are needed to make the code more maintainable and keep it extensible in the long run, and an initial draft and braindump of the start of that process and those changes. —TheDJ (talk • contribs) 19:49, 27 May 2013 (UTC)

Yes, "rules" is a side-effect of how we try to write this newsletter, i.e. in simple language. "Rules" is simpler to understand for non-native English speakers than "guidelines". It's often difficult to find a balance between accuracy and simplicity :) guillom 09:22, 28 May 2013 (UTC)

Per someone's suggestion at WT:Notifications, I've put SineBot onto the blacklist. Nyttend (talk) 18:03, 28 May 2013 (UTC)

VisualEditor fortnightly update - 2013-05-27 (MW 1.22wmf5)

Hey all,

Here is a copy of the regular (every fortnight) update for the VisualEditor project, so that you all know what is happening (and make sure you have as much opportunity to tell us when we're wrong, as well as help guide the priorities for development and improvement):

VisualEditor was updated as part of the wider MediaWiki 1.22wmf5 branch deployment on Monday 27 May. In the two weeks since 1.22wmf4, the team attended the Wikimania Hackathon in Amsterdam, working with the community to improve VisualEditor and help them, and, ahead of VisualEditor's launch as the default way users will edit our wikis in beta, worked on the new features: Categories, Templates, References and Images.

In terms of improvements to the integration with MediaWiki, we have a number of changes. When the diff result is null because we think you've made no changes, we say so rather than give a confusing blank diff table (43754); wikitext edit conflict handling is now integrated into the save dialog rather than punting you out of VisualEditor (42522); minor edit checkboxes get pre-set (48347), and you get a warning about not having set an edit summary (47752), based on your preferences; when editing old revisions, you are now warned about this (47683); we now show "Editing …" in the browser title when in VisualEditor, like for the wikitext editor, so that it's clear which of your tabs is editing (48272).

We give a better error message if Parsoid is unavailable during diffs (47581). If the edit token we're using is detected as invalid, we ask for a new one (42984). The edit summary field correctly counts the number of characters entered when using non-ASCII characters (47718). The <visualeditor-feedback-link> message is now shown in the content language, rather than the user language (47730). We now won't load for pages which are redirects as they can't yet be edited (47329). We show "create source" rather than "edit source" for the wikitext editor tab for non-existent pages (47421). We don't disable the save dialog when editing a prior revision (48584). Pre-formatted text blocks now word-wrap rather than character-wrap (38043).

Auto-selection expansion now behaves at the ends of paragraphs as elsewhere (48487), and the link inspector now understands that the first characters of links being auto-capitalised based on wiki context doesn't make them different links (48476). The toolbar clears floated items to avoid mis-alignment (48734). VisualEditor should now work with non-BMP Unicode characters (48630). Finally, we fixed a couple of breaks in the link inspector button (48509 and 48549), in pasting text (48602 and 48603), and some problems when moving back to read mode whilst VisualEditor was loading (48520 and 47813).

A complete list of individual code commits is available in the 1.22/wmf5 changelog, and all Bugzilla bugs closed in this period on Bugzilla's list.

Per the MediaWiki deployment roadmap, this should be deployed here on Monday 3 June.

Hope this is helpful! As always, feedback gratefully received, either here or on the enwiki-specific feedback page.

Jdforrester (WMF) (talk) 11:34, 28 May 2013 (UTC)

Intrusive image annotations in good-topic display templates

Time to bring some attention to this; it's been languishing for months. Please read my brief post at Wikipedia talk:Good topics#Annotated images (or look at this image for a summary of the problem). Waltham, The Duke of 13:39, 28 May 2013 (UTC)

Categories out of sync

Does anyone know why this template, which is categorized into two speedy deletion categories, seems to be missing from both of them? I tried purge but it didn't help. GregorB (talk) 18:35, 24 May 2013 (UTC)

note the words in the category page

"This list may not reflect recent changes (learn more)."

the last two words in this sentence are a link - use it. peace - קיפודנחש (aka kipod) (talk) 19:01, 24 May 2013 (UTC)

Null edit made... Feeling a little bitey and annoyed with people today kipod? It's all good, everyone has their days. Technical 13 (talk) 19:07, 24 May 2013 (UTC)

absolutely not. pointing the fact that something is explained (somewhere) and suggesting the person might want to read the explanation is not like saying "RTFM" - it's more like giving someone the link to "TFM". the assumption is that the person was not aware of the this piece of documentation, and pointing to it is doing them a service. peace - קיפודנחש (aka kipod) (talk) 22:21, 24 May 2013 (UTC)

I know sometimes changes are not propagated instantly, but it's been three weeks since the template was added. It was supposed to be a speedy deletion, however the template got stuck in nowhere land, so the admins couldn't see it. I was about to try the null edit as suggested, but you just beat me to it. Problem solved, thanks! GregorB (talk) 19:15, 24 May 2013 (UTC)

I actually had the same problem with Template:Matlock and am now thinking that maybe Joe's Null Bot by Joe Decker should be put to work here as well since these are suppose to be speedies... Technical 13 (talk) 19:48, 24 May 2013 (UTC)

• Category links are MediaWiki design flaw so use null-edit bypass: The failure to update category links, even after 3 weeks, is a massive failure of the MediaWiki software, and imagine how intensely the developers have had to struggle to overcome all the bizarre, convoluted quirks of the initial MediaWiki versions (think: "MediaWacky"). However, accurate categories are important, and so the tactic of using a null-edit bot to "knock some sense" into the MediaWiki database links is a reasonable option. In this age, of layer upon layer of software modules, it is becoming nearly impossible to keep pace with problems; however, the potential for "crowd-sourcing" or "expert-group-sourcing" might resolve problems faster, as more people work together to solve vast numbers of software problems. In fact, it might make sense to have "null-edit backlog drives" to encourage hundreds of editors to help correct category links in some high-priority categories, perhaps in articles about medical treatments or such. However, the future seems clear to me: "Everyone worry about performance" (versus the archaic wp:PERF), and together perhaps we can quickly find the causes of the massive software bugs in the Wikipedia software or else, help to manually (or Bot-wise) circumvent the problems to lessen their impact. Perhaps some day we might look back on the list of "Top 20 appalling MediaWiki software problems" and remember why it took so long to fix some of them. But keep looking for solutions. -Wikid77 (talk) 21:54, 24 May 2013 (UTC)

"Everyone worry about performance"? WP:PERF says some very wise things. Though you know of it, you don't understand all of it, particularly the "Editors still have a role to play" section. The main point of the page is worries about server performance are not a reason to avoid useful edits (Be bold, etc). Where a performance problem becomes visible to users, technically-minded editors can find ways to make improvements (e.g. rewriting a slow template using Lua). "Everyone worry" would mean non-technical users being afraid to make edits if they are unsure of the performance impact, or taking actions based on superstitions about performance rather than a good understanding of it. Such actions could waste their time and that of others and make articles harder to maintain, with probably no effect on performance.

Though editors can improve performance in isolated areas such as problematic templates, we don't have access to the servers for making site-wide improvements. Hence, most performance issues are only for developers to worry about, since they are the only ones able to fix them. If you really want to make improvements to performance, you should become a developer rather than encouraging regular editors to worry about things they have little control over. – PartTimeGnome (talk | contribs) 16:45, 27 May 2013 (UTC)

So, am I right in thinking people would like Joe's Null Bot to handle whatever the equivalent CSD T3 categorization issues are? If there is consensus on that, I'll file a BRFA. Give me a kick if I forget to check back here. --j⚛e decker^talk 01:16, 29 May 2013 (UTC)

Filed at Wikipedia:Bots/Requests_for_approval/Joe's_Null_Bot_6 --j⚛e decker^talk 20:41, 29 May 2013 (UTC)

User:Joe Decker, your request has been approved ·addshore· ^{talk to me!} 22:39, 29 May 2013 (UTC)

Man, you are everywhere!  :) I'll get it running in a few minutes, thanks. --j⚛e decker^talk 22:48, 29 May 2013 (UTC)

Namespacing meta categories

The Czech Wikipedia namespaces its maintenance categories, for example Category:Tracking:Missing coordinates or Category:Error:coordinates greater the 360 degrees. Any reason we shouldn't do likewise? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:52, 25 May 2013 (UTC)

The former: Category:Articles_needing_coordinates. The latter we have: Category:Pages_with_malformed_coordinate_tags. —TheDJ (talk • contribs) 13:37, 25 May 2013 (UTC)

Thank you; I'm familiar with both of those. I'm not asking for new categories, I'm suggesting that we change how we name them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 05:53, 26 May 2013 (UTC)

My response fell into the category of don't post while your are half drunk at a Hackathon :D —TheDJ (talk • contribs) 18:41, 26 May 2013 (UTC)

They aren't namespaces. They are just names with a colon. For example, cs:Kategorie:Systém:Skryté kategorie is a category called "Systém:Skryté kategorie". "Systém:" is the first 7 characters of the name and doesn't have any of the namespace features. PrimeHunter (talk) 14:02, 25 May 2013 (UTC)

Not in the MediaWiki sense, perhaps, but in the general sense they are. The Czech guys do clever stuff with them. I'll invite one to comment here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 05:53, 26 May 2013 (UTC)

This does seem rather useful to me. Especially with Special:PrefixIndex, you can do a few interesting things, that are simply not possible with our current tree based structure. It does raise the question about why this isn't actually possible with the core software, but i'd be in favor of actually trying this out with at least our error categories. —TheDJ (talk • contribs) 18:41, 26 May 2013 (UTC)

Why ask here, not at WP:VPR? This sounds like a good idea. It would be eminently unhelpful with content categories because of the rigid hierarchy that it imposes, but a hierarchy is helpful for error and tracking categories, if for no other reason than that it clarifies what's wrong and what's just being watched. Nyttend (talk) 16:37, 27 May 2013 (UTC)

Because it's a technical matter. I explicitly refer to maintenance categories, thereby excluding content categories. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:25, 28 May 2013 (UTC)

seems like a good idea to use a common prefix, which helps with finding them. Frietjes (talk) 15:33, 28 May 2013 (UTC)

Now that we have some agreement, which categories shall we rename, as a pilot? Or do we need wider discussion? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:25, 28 May 2013 (UTC)

the proposal is harmless, but i don't think it's extremely useful, either. basically, the proposal is to implement some kind of "classification system" by prefixing the page name with its class (in this case the "page" is a category, but in reality this is immaterial - one can propose similar system of naming with "classification:" prefix for pages which are not categories themselves, with exactly the same reasoning).

however, the mediawiki software _already_ has pretty capable and efficient classification system, IOW, categories.

taking a bunch of maintenance categories and renaming them to have "Tracking:" or "Error:" prefix will not achieve more than creating a "tracking" or "error" new categories, and adding the categories under discussion to those categories.

just my $.02, of course. peace - קיפודנחש (aka kipod) (talk) 18:52, 28 May 2013 (UTC)

As TheDJ notes above, "with Special:PrefixIndex, you can do a few interesting things, that are simply not possible with our current tree based structure". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:36, 28 May 2013 (UTC)

the only such "interesting thing" i know of are some sophisticated searches. afaik, the search system has an "incategory:" feature that will let you do just as much if we categorize those categories rather than name-prefixing them. however, it is very likely (actually it's certain) that there are things i *do not* know. can you please elaborate? what interesting things are we talking here? thanks a bunch, peace - קיפודנחש (aka kipod) (talk) 22:41, 29 May 2013 (UTC)

Contribs from a CIDR range out of date?

Hello all, this may have been raised before but I can't find it. I'm looking at contributions from a CIDR range, in this case 103.247.49.128/26, and so am looking at the contributions for 103.247.49.0/24, as the tool only allows /16 and /24. I get this output [36]. However, IPs from this range were editing yesterday (if not before) - for instance 103.247.49.133 thus [37] - and they don't show up. Is there a lag on this tool? Black Kite (talk) 10:46, 27 May 2013 (UTC)

• In fact, looking at it, that IP edited in December 2012 [38] as did this one [39], and they don't show up either. Whilst this one was editing recently, but only their October 2010 diff shows up on the list, and nothing after. [40]. Did something break between 27 November - the latest diff that shows up - and 7 December - the earliest diff that doesn't? Black Kite (talk) 10:53, 27 May 2013 (UTC)
• EDIT: OK, fixed - I copied User:Splarka/contribsrange.js into my .js file, disabled the gadget, and it works. Looks like Splarka made some changes to it recently to fix things. I presume, however, that this version should now be copied across to MediaWiki:Gadget-contribsrange.js? (I'm not going to do it myself in case I break something). Black Kite (talk) 11:12, 27 May 2013 (UTC)

I can't really support all my old scripts anymore, but this one did seem strange. And as this is a popular gadget I spent some time looking into it. I sure don't remember this being an issue when I was writing and testing the script five years ago, but possibly I wasn't paying specific attention to it. I originally did a quick patch job when this came up a few days ago, but this fix should be closer to the UI behavior. I suggest some comprehensive testing before requesting a gadget sync. --Splarka (rant) 08:34, 28 May 2013 (UTC)

Okay, so here's the skinny. When I made contribsrange.js I incorporated as much of the Special:Contributions UI into the code as was practical (that could be mapped to api.php?list=usercontribs parameters). An easy one was &ucstart, which I could just fill in via the year/month box. I did it somewhat sloppily, interpreting "from x and before" as "from before x". At the time, the year box was blank by default, but a recent change started filling it in for some reason. This caused the &ucstart parameter to always be included, which meant no new contributions past the end of the previous year would show by default. --Splarka (rant) 21:15, 28 May 2013 (UTC)

Thanks for the tool and for suggesting a temporary workaround here. While this works with the workaround, I'm seeing a bit more of a problem: an actual CIDR search doesn't work at all, even with the workaround. --Elvey (talk) 01:56, 29 May 2013 (UTC)

Works for me: 46.235.152.0/24 vs 46.235.152*. The CIDR applications are very limited, as it either has to do a lookup of each individual IP (which is limited to 50 parameters, so it can only do a /27 to /32), or a prefix (which is why /24 and /16 work). When I originally wrote it, the number of ucuser parameters was only limited by URI length (/24-/32 worked), so it made more sense to support CIDR formats. --Splarka (rant) 06:15, 29 May 2013 (UTC)

Whoops. Mine didn't work because 46.235.152/24 is not valid shorthand for 46.235.152.0/24. Thanks for the help.

--Elvey (talk) 02:59, 30 May 2013 (UTC)

Add Links unexpected error

Clicking on the "Add Links" option in the Languages section to the left of article Kreshnik Çipi in order to add a link to the article on sq.wiki.x.io and I get "An unexpected error occured" - any ideas, Thanks GrahamHardy (talk) 17:09, 28 May 2013 (UTC)

As you didn't tell us at which step you've received this error and whether there were any further details associated with it, I can only guess the issue. If you're using Internet Explorer 9 (or less) you sadly can't use the widget, as Internet Explorer doesn't support the needed techniques. If that's the case you wont see the "Add links" link at all after June 3 as from then on it's being hidden for users with incompatible browsers (gerrit change). If you're using a more current version of Internet Explorer or another browser it's most likely a different issue. In this case the "Details" which can be found below the error probably read like "Site link [[sqwiki:Whatever]] already used by item [[Q123456789]].". That is a known bug on which we're currently working. Cheers, Hoo man (talk) 21:59, 28 May 2013 (UTC)

Yes I'm using IE8, which explains my problem... Can someone else perform the needful on this page ? Thanks GrahamHardy (talk) 09:05, 29 May 2013 (UTC)

Sure, but we'd like to know what the name of the article at sq: is. --Redrose64 (talk) 11:56, 29 May 2013 (UTC)

try sq:Kreshnik Çipi. peace - קיפודנחש (aka kipod) (talk) 12:47, 29 May 2013 (UTC)

Done.—Emil J. 12:50, 29 May 2013 (UTC)

Problem using Twinkle

Twinkle is not working for me right now -- it's not showing up as an option to use when viewing diffs and it's not coming up on the drop down menu at the right of the page. Is there a general problem in Wikipedia with Twinkle at the moment or is it my computer? Winkelvi (talk) 01:18, 29 May 2013 (UTC)

Yep, I came here to report the same problem. ---The Old Jacobite_{The '45} 01:20, 29 May 2013 (UTC)

Yeah, the dropdown menus on the sidebar aren't collapsing and the search engine window is not there either. AutomaticStrikeout  ?  01:24, 29 May 2013 (UTC)

Thanks for the confirmation. Winkelvi (talk) 01:25, 29 May 2013 (UTC)

Well, I just uploaded a new version, but currently I'm getting errors from bits.wikimedia.org, don't know if's the same issue you have. _→AzaToth 01:27, 29 May 2013 (UTC)

Seems to be my fauly, but not really my fault, possibly my commit has triggered a bug somewhere on the backend, hopefully it will resolve in no time. _→AzaToth 01:36, 29 May 2013 (UTC)

Is it possible that popups have also stopped functioning? --After Midnight ⁰⁰⁰¹ 02:41, 29 May 2013 (UTC)

Yep. My nav popups aren't working either. Firefox 22. Dave Dial (talk) 03:07, 29 May 2013 (UTC)

For me it's like nothing javascript is working at all... no UTC purge clock, watchlist isn't collapsing, Twinkle isn't working, it's no longer trying to stop me from navigating away from a page where I've made edits but not saved, etc, etc. Firefox 21. --ElHef (Meep?) 03:12, 29 May 2013 (UTC)

Of course, as soon as I said that, it looks like it's all come back. Disregard, at least from me. --ElHef (Meep?) 03:16, 29 May 2013 (UTC)

Ditto Dave Dial (talk) 03:16, 29 May 2013 (UTC)

I found that there were very high levels of "Fatal error: Allowed memory size of 183500800 bytes exhausted" in the error log going on, all seemingly related to attempts to load JS including Twinkle. And even a query loading only Twinkle was erroring out. And the errors seem to have begun at the same time that MediaWiki:Gadget-Twinkle.js was recently edited. So I asked an enwiki admin to revert that recent edit, and sure enough the fatal errors stopped. Working hypothesis at this point is that Twinkle has just grown too huge; I'll try to get some others more familiar with this sort of thing to look at it tomorrow. In the mean time, please don't make Twinkle any bigger. BJorsch (WMF) (talk) 03:21, 29 May 2013 (UTC)

Hmmm. 530,733 bytes to 537,981 bytes did it? I agree that this particular page is extraordinarily large, but whatever is allocating 183,500,800 bytes of memory for this file seems to be a bit broken. That seems like, err, a lot of overhead. --MZMcBride (talk) 02:18, 30 May 2013 (UTC)

bugzilla:29784 --MZMcBride (talk) 02:26, 30 May 2013 (UTC)

I had the same problem for approximately an hour (7:20 PM - 8:20 PM PT). However, I'm wondering if it was a server issue with Wikipedia, as loading performance in general was really slow during that time. Another issue I had during that time was that the toolbar in the editor wasn't appearing. - Amaury (talk) 05:57, 29 May 2013 (UTC)

Twinkle not working

The next complaint is the exact same problem. I'm stupid and didn't look above before writing. TheOneSean ^{[ U | T | C ]} 01:49, 29 May 2013 (UTC)

For about a month now, I've been using Twinkle for vandalism fighting, but mostly leaving Talkback on other people's pages. The last time I logged in, I didn't get a Twinkle tab where it normally is. I checked preferences. It says Twinkle is enabled. I unchecked it, saved, checked it again, saved, refreshed. No dice. I logged out, logged back in. Nope. I'm using Chrome. Any ideas? Thanks, TheOneSean ^{[ U | T | C ]} 01:48, 29 May 2013 (UTC)

Score block

RESOLVED: Omit "\version" in score-tags. -Wikid77 08:14, 30 May 2013 (UTC)

I still don't understand how to get this, which compiles fine in Lilypond, to display in an article with the <score> markup. Help?

\version "2.16.2"

\new Score {
  \new Staff {
    \relative c' {
      \time 3/4
      \clef treble
      \key g \major
      
      \partial 4 d4 |
      b'4( c) b | d4( b) a | g( a) e | g fis e |
      d2 d4 | g4( a) b | a2 g4 | fis2 \bar "||"
    }
  }
}

Thanks! --SarekOfVulcan (talk) 20:26, 28 May 2013 (UTC)

just remove the "Version" part, and all will be well. peace - קיפודנחש (aka kipod) (talk) 20:30, 28 May 2013 (UTC)

Argh. I don't know why that didn't happen for me at some point along the way. Thanks! --SarekOfVulcan (talk) 20:39, 28 May 2013 (UTC)

Strange. I could swear this output was working earlier today, and now it's producing an error message. Wikimedia seems to have broken its configuration. Filed as bugzilla:49004. --MZMcBride (talk) 03:39, 31 May 2013 (UTC)

Problems in archiving the discussions

Hello people,

I was looking for my discussion on the Technical Village Pump, but I did not find it.

And now I see that this discussion has been moved to an archive less than 6 days after a message was written in it !

This is crazy.

This is way too soon, and this creates further technical problems.

You may see details and sharings of my point of view in these discussions : this discussion, that discussion.

In this archiving, splitting the page by date instead of by subject is simply stupid. The subjects are important, the dates are meaningless.

A lot of discussions started 5 or 6 days ago or even 2000 years ago and are still relevant and are being hotly discussed today.

This definitely has to be improved.

Cheers,

--Nnemo (talk) 18:10, 29 May 2013 (UTC)

How do you propose that we make improvements, while maintaining manageable page sizes? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:29, 29 May 2013 (UTC)

Well, something like this and that. StackExchange uses its Meta system to receive, discuss and manage bug reports and feature requests. This is not a small idea that could be done in 5 minutes. But this is much more adapted. In the meantime, put the liquid discussions like these here. Thank you. --Nnemo (talk) 19:22, 29 May 2013 (UTC)

WP:LQT? No, thanks. --Redrose64 (talk) 19:57, 29 May 2013 (UTC)

according to the edit summaries of the archiving bot, it seems that it archives any discussion older than 5 days. typical page size seems to hover around 150K. personally i think this can be relaxed: leave discussion longer before archiving, maybe 7 or 10 days. naturally, this will result in larger typical page size. is 250K prohibitively large? personally, i do not think so.

i propose to raise the archiving threshold to 8 days. peace - קיפודנחש (aka kipod) (talk) 16:02, 30 May 2013 (UTC)

It used to be 7 days. It was reduced to 5 days on 29 November 2012. The discussion for this change is at Wikipedia talk:Village pump/Archive 8#Lowering the archive time. (There was no announcement of this discussion on VPT itself or its talk page.) – PartTimeGnome (talk | contribs) 21:29, 30 May 2013 (UTC)

Perhaps have long-term 2nd page "technical_longer"

I am thinking that some conversations, or questions, could be placed in a long-term issues page, such as named "(technical longer)" which were still tech issues but likely to run weeks longer (less frequent auto-archiving there), to avoid archiving too soon. That would also allow faster pruning of this page, where some people would realize an issue would need "longer" discussion, and then note a new thread there, as linked from here to allow such threads to be closed here even sooner. Some people have noted my answers seem too detailed, by including analogies or related tangents, and those topics might also be transferred to the tech-longer page, for possible cross-influence between related techniques. In fact, a good reason to open a thread at tech-longer could be auto-archiving before satisfactory answer, so just link the Archive_xx/topic and resume discussion as thread on the tech-longer page. In cases of slow-down there, could post a reminder thread here. I think that is the solution, so I have listed some related questions below, for separated discussions. -Wikid77 15:18, 30 May 2013 (UTC)

What page name to use for the tech-longer page, perhaps tech-extra, as VPTX? -Wikid77 15:18, 30 May 2013 (UTC)

Should we have cross-link templates to wikilink both pages A<-->B by shortcut template names? -Wikid77 15:18, 30 May 2013 (UTC)

Should we use same thread title on both tech-pump pages to simplify cross-links? -Wikid77 15:18, 30 May 2013 (UTC)

Should we note user right to unmove back, as in write-up to note person has right to unmove thread back to here, as when related solutions come faster? -Wikid77 15:18, 30 May 2013 (UTC)

Sounds too complicated...our current system works, so why "fix" it? People are welcome to reopen threads from the archives if they so desire. Theopolisme (talk) 16:34, 30 May 2013 (UTC)

Some people don't reopen the threads by posting to this page though, and instead comment directly to the archive page. This one is, I think, the most recent that went unacknowledged, but there have been several since that where either they weren't expecting a reply (thankyou messages) or somebody else happened to notice and informed them accordingly. --Redrose64 (talk) 16:46, 30 May 2013 (UTC)

What about an editnotice for all archive pages (i.e, prefix "Wikipedia:Village_pump_(technical)/Archive")? Theopolisme (talk) 17:12, 30 May 2013 (UTC)

• Wouldn't it be just as easy to prepend any discussion that may need this extra time with {{Bump|days}} which automatically tags the section as do not archive for that duration no matter how stale it gets and skip the extra page and trying to remember and find threads on other pages? Technical 13 (talk) 16:58, 30 May 2013 (UTC)

• A tech-extra forum fixes 5 issues: rushed archiving, staleness, retro-analysis, bloat & fractionating: The problem here is not just rushed archiving to then require a restart of a long-term topic. There is also a major problem of staleness, here already, of topics which experts could see to move to a tech-extra forum (such as tricks to bypass this month's "13" user-interface changes). Plus, having some topics sitting for weeks in a tech-extra page would help the "retro-analysis" of issues, to rethink plans from prior weeks, and perhaps to post links to the specific follow-up templates, help-pages, gadgets (etc.) which now make sense, in retrospect about a topic weeks ago. Next, there is also the opportunity to reduce obvious bloat here, to move some threads to tech-extra sooner, and also append to related long-term threads already in that page. Then the moved topics could be pre-archived, perhaps with a dedicted thread here, "Topics moved to tech-extra May 2013" with one-line links to short titles of the tech-extra topics. Finally, by quickly moving extensive discussions to the tech-extra page, then the archives there would become more comprehensive of full discussions, not fractionated bits and pieces rushed in spurts into the main PUMPTECH archives. The overall concept, for the extra page, would function as a form of "discussable archive" (as people noted above) where the history-log of edits would reflect actual long-term discussions. People could reply, "I'll answer over at tech-extra, with direct links to related issues". Hopefully, a tech-extra page would surpass as a re-arrangeable "wp:Liquid Threads" with methods to restructure long-term discussions of issues which spanned months (plus strike bars in old misleading comments), while streamlining the main VPT page and reducing the rushed archives. Bottomline: we need a "discussable archive" structure, and I think a tech-extra page would help. -Wikid77 (talk) 20:00, 30 May 2013 (UTC)

We could go a long way to sorting the "bloat" problem if some of the posts on this page were a lot shorter. --Redrose64 (talk) 20:36, 30 May 2013 (UTC)

Demand tweets as VPTWEET page! Yet many issues need details to solve. But the real problem is many topics rehashed weeks here, as count of signatures=276. Consider if 15 threads already at tech-extra, reduced to just 22 here. -Wikid77 00:40, 31 May 2013 (UTC)

We can relax the archive limits a bit. It seems to me that compared to 4 years or so ago, this page has a lot fewer topics then it had back then. Back then it hardly dropped under 40 or so topics. These days its usually between 20 and 35. —TheDJ (talk • contribs) 21:27, 30 May 2013 (UTC)

Beware smaller size is due to rushed archiving at "5d" otherwise would be huge 60-70, as people combine threads. See VPT 6 days ago: oldid-330, would be +30 topics now. Wikid77 00:40, 31 May 2013 (UTC)

Extra links for images on Commons

When viewing images on Commons, I notice there are several extra links: included are "Google images" and "Tineye search." Where is the script on Commons located for that? Magog the Ogre (t • c) 04:31, 30 May 2013 (UTC)

They're gadgets, found at commons:Special:Preferences#mw-prefsection-gadgets under the "Maintenance tools" heading. Judging by commons:MediaWiki:Gadgets-definition, the files are: commons:MediaWiki:Gadget-Tineye; commons:MediaWiki:Gadget-Tineye.js; commons:MediaWiki:Gadget-GoogleImages; and commons:MediaWiki:Gadget-GoogleImages.js. --Redrose64 (talk) 09:26, 30 May 2013 (UTC)

Watchlist in bold

Unread items in my watchlist have suddenly started going bold, despite the relevant option in Special:Preferences#mw-prefsection-gadgets being unchecked. Is this a bug or somesuch? GiantSnowman 19:08, 29 May 2013 (UTC)

This may be related to #Problem using Twinkle above. If bits.wikimedia.org has some problem, all kinds of weird stuff may happen. — Edokter (talk) — 19:39, 29 May 2013 (UTC)

just tried it (i *do* like this feature, so i had to temporarily disable the gadget in order to test) and it works exactly as advertised for me.

User talk:Edokter may have hit the nail on the head, but my guess is that he didn't, and your problem is that you have some old junk stuck in your browser's cache. try hitting Ctrl+⇧ Shift+Delete (presuming windoze, and one of the "big 3" browsers: i do not know how to drop the cache on mac's browsers, or any windoze browser other than ff/chrome/ie), and select "empty cache" or "drop cache" or "delete temporary files" or whatever your browser use to say "clear the cache". peace - קיפודנחש (aka kipod) (talk) 19:44, 29 May 2013 (UTC)

That didn't work. GiantSnowman 19:58, 29 May 2013 (UTC)

i disabled javascript in my browser, and the gadget still works for me (this gadget is purely CSS - no JS involved). this is why i expressed doubt of the explanation that this is similar problem to the one bugging twinkle users and discussed elsewhere on this page. can you try to see if you have the same problem with a different browser? peace - קיפודנחש (aka kipod) (talk) 14:34, 30 May 2013 (UTC)

The section at the bottom of the editbox that usually holds the <charinsert> links is just solid text for me at the moment so I'm assuming there is something buggy going on with the JavaScript on the site at the moment. mw-edittools I think is the name of the section acting up for me. Technical 13 (talk) 19:52, 29 May 2013 (UTC)

This happened to me once before. I just refreshed the page and it went back to normal. I assume it's the pages you haven't visited on that computer which are going bold; that's what happened to me, which I assumed had something to do with the was the Simple English WP works talk pages, because they do it the same way. Greengreengreenred 14:40, 30 May 2013 (UTC)

actually, no: it's not "pages you haven't visited on that computer", it's "pages you haven't visited while logged in". the information is maintained on the server (rather than, say, in cookies on your computer), and does not depend which computer or which browser you used when reading the page. the system is pretty sophisticated: for instance, if you click "history" and read an old version of the page, this action will not be counted as "visit", but if you compare the latest version to a previous one, this "diff" operation *will* count as "visit" (as it should). peace - קיפודנחש (aka kipod) (talk) 14:50, 30 May 2013 (UTC)

Still not working guys. GiantSnowman 21:39, 30 May 2013 (UTC)

you did not answer my question, so here goes: can you try to see if you have the same problem with a different browser? peace - קיפודנחש (aka kipod) (talk) 22:48, 30 May 2013 (UTC)

It's fine on an older version of the same browser (IE) at a different computer, and it's fine on my iPad - but not on IE10. GiantSnowman 09:44, 31 May 2013 (UTC)

can you do me a favor? from your "watchlist" page, hit F12 and select "console" (it will probably ask you to refresh the page at this point - do it), and post here if you see any errors (typically appear in red) on the console? thanks, peace - קיפודנחש (aka kipod) (talk) 13:49, 31 May 2013 (UTC)

Guys, I think it was because I was in 'compatibility' mode. Seems to be fixed now... GiantSnowman 18:39, 31 May 2013 (UTC)

User contributions oddity

Not sure if there is something there that needs fixing, but I thought it was pretty strange. See the feedback summary by 176.42.16.120 at Wikipedia:Automatic edit summaries. I don't think it's supposed to do that... --Bongwarrior (talk) 17:58, 30 May 2013 (UTC)

Looks like the parser is evaluating the template...Oliver, if you're out there, since AFT is your baby, take a look? Theopolisme (talk) 18:01, 30 May 2013 (UTC)

It's...oh lord. Escaping exists for a reason :/. Okay, I'll let the devs know. Okeyes (WMF) (talk) 20:48, 30 May 2013 (UTC)

They've been poked :). Given his other feedback, of course, it's plausible it's not being evaluated and is being escaped properly, and he's just typing a mess of code in as feedback :). Okeyes (WMF) (talk) 20:50, 30 May 2013 (UTC)

Yeah, that's not really a good idea. Code in feedback posts should be treated exactly as it would be in edit summaries. Graham87 08:13, 31 May 2013 (UTC)

Totally agreed! There's now a patch in gerrit which should fix the problem at our next deployment. Thanks, all :). Okeyes (WMF) (talk) 11:09, 31 May 2013 (UTC)

A couple technical updates

The experimental Thanks extension was deployed to English Wikipedia on May 30. Also, as of May 30th, videos are now displayed in a modal viewer when you click on the thumbnail in an article. See Congenital insensitivity to pain for an example. Kaldari (talk) 00:55, 31 May 2013 (UTC)

How do I get rid of the thanks extension?--Bbb23 (talk) 01:02, 31 May 2013 (UTC)

@Bbb23: Wikipedia:Notifications/Thanks#How_to_turn_off_this_feature Theopolisme (talk) 01:45, 31 May 2013 (UTC)

Yes, I saw that after I posted, Theopolisme, thanks. I'd like to find a way, though, to turn just this new feature off without necessarily turning off other new features. That check box makes it sound like it turns off all new experiments. My guess is someone has already created a script to do it; I just have to find it.--Bbb23 (talk) 02:00, 31 May 2013 (UTC)

You can add

a.mw-thanks-thank-link {display:none;}

to your Special:MyPage/common.css file to hide the "thanks" link; however, this is not ideal, since it will still leave the vertical pipe next to where the "thanks" link belongs...I'm not a js/css expert, but somebody or other should be able to help with that. Theopolisme (talk) 03:12, 31 May 2013 (UTC)

Yeah, Theo, that was my first thought too—works fine, but like you say, it leaves the () there. I don't think that can be helped, except on the developers' side—the parentheses are hard-coded into the HTML; the only thing they're a part of is <div id="mw-diff-ntitle1">, which is the entire Revision as of ... (thank) line. If the devs would include that set of parens in a span or something, then it could work. Ignatzmice•talk 03:37, 31 May 2013 (UTC)

I'll take a look at it in an hour or so. I'm pretty sure we can get rid of the extras like I did with my script that gets rid of rollback and block buttons... gotta catch a bus to school first. Technical 13 (talk) 10:51, 31 May 2013 (UTC)

Okay, if you are just looking to get rid of the (thank) from diff pages... Adding the following code to your common.js should do it for you: importScript('User:Technical 13/Scripts/NoThanks.js'); // [[User:Technical 13/Scripts/NoThanks.js]] — If you want to remove it from other pages (like History pages), that can probably be done too, but I don't want to spend much time on it unless requested. Happy editing! Technical 13 (talk) 12:55, 31 May 2013 (UTC)

UPDATE: The script now removes all "thanks" links from history and differences pages. If there is someplace else you want them gone from (are they anywhere else?) point me to them and I'll add it to the script. Technical 13 (talk) 20:58, 31 May 2013 (UTC)

urls with square brackets

How do I include a citation that uses the square bracket as part of its url? The address is http://tools.morningstar.co.uk/uk/stockreport/default.aspx?tab=3&vw=story&SecurityToken=0P00007OBL]3]0]E0WWE$$ALL&Id=0P00007OBL&ClientFund=0&CurrencyId=GBP&story=7400228704134. Currently it truncates and doesn't reach the target page. Please see this. Thanks in advance. -- Ohc ^¡digame!_{¿que pasa?} 07:15, 31 May 2013 (UTC)

Replace the right brackets with %5D, the equivalent percent-encoding. As mentioned at the relevant help page, you could also use the {{urlencode}} magic word, but the former solution is cleaner IMO because it works everywhere (especially on mirrors/forks and non-MediaWiki sites). At any rate, I've fixed the problem. Graham87 07:42, 31 May 2013 (UTC)

Thanks. -- Ohc ^¡digame!_{¿que pasa?} 08:06, 31 May 2013 (UTC)

WP:FRS

RESOLVED: Template fixed so wp:FRS runs 4 seconds. -Wikid77 17:05, 31 May 2013 (UTC)

Per discussion at Wikipedia:Administrators' noticeboard#What_is_wrong_with_WP:FRS?, there seems to be a problem in the reliability of the aforementioned page. When I make an edit, it gets through, but gives some a wikimedia error. The error it gives is on the page linked earlier. If anyone knows anything more, that would be great, thanks! -- ^(T) Numbermaniac _(C) 12:36, 31 May 2013 (UTC)

Just to confirm I also tried editing the page and got a time out. There does seem to be quite a lot of templates on the page and the NewPP report is below.--Salix (talk): 12:45, 31 May 2013 (UTC)

NewPP limit report

Preprocessor visited node count: 253239/1000000

Preprocessor generated node count: 46210/1500000

Post‐expand include size: 1083093/2048000 bytes

Template argument size: 300421/2048000 bytes

Highest expansion depth: 18/40

Expensive parser function count: 1/500

• FIXED: Reformats WP:FRS in 4 sec not 28s as 7x-12x faster: I have rewritten and tested the username-linker Template:Frs_user, to set the username wikilinks 12x times faster than before. So, the wp:FRS page can reformat, or edit-save, within 4 seconds now, rather than the typical 28 seconds which would stretch to 60-sec timeout on busy servers. Thank you both for reporting the performance problem, and I am sorry wp:FRS had been running the slow 28 seconds for over 2 years. If everyone worries about performance, more, then we can fix these major problems years sooner. Are there any related slow pages? -Wikid77 (talk) 17:05, 31 May 2013 (UTC)

Change to the 'new editor getting started' tag

Hi everyone,

If you check RecentChanges often or have articles tagged for issues like copyediting on your watchlist, you might have noticed the "new editor getting started" tag. These edits are made via Wikipedia:GettingStarted, which is delivered to new editors after the first sign up. The change that we made yesterday is that, if you're autoconfirmed, your edits won't get tagged, even if you edit via the GettingStarted dashboard. Previously, all of the edits that came via that interface were tagged, even if you weren't really new.

Considering that most of the edits already do come from genuinely new editors, I don't think the volume level will change for the tag significantly. (Right it's about 100-300 edits a day [41]). However, since admins or patrollers might have noticed this tag, or used it for looking at newbie contributions as a group, I wanted to keep everyone in the loop about what the tag represented. Steven Walling (WMF) • talk 18:50, 31 May 2013 (UTC)

Page not displaying properly

There is a problem at 2002 Detroit Tigers season, with some of the text in the lower half of the article not displaying all the way across the screen. AutomaticStrikeout  ?  01:47, 1 June 2013 (UTC)

Fixed. --Patrick87 (talk) 01:58, 1 June 2013 (UTC)

Thank you. AutomaticStrikeout  ?  02:04, 1 June 2013 (UTC)

Cropping DNB for name variations (redirects)

First let me say I'm not a programmer, so don't beat me for suggesting something infeasible. :) But anyway, he's my thought:

Consider the article Maimonides for instance. At the bottom, via {{Authority control}}, it is connected to this GND/DNB profile (DNB as in Deutsche Nationalbibliothek). As you can see, the DNB profile lists a couple of dozens of alternative spellings of Maimonides' name. So I was thinking how great it would be if the Wikipedia software would automatically extract these name variants and create redirects to the actual article (not just to Maimonides, of course, but to all Wikipedia articles with GND identifiers). The data is also available in RDF format, so machine readability shouldn't be an issue here (again I'm not a programmer).

Is it possible to do this? Because it would save Wikipedia editors a lot of time and energy not having to create all those redirects manually. --bender235 (talk) 16:52, 24 May 2013 (UTC)

• Sourced variant names are interesting but WP overrun by variants: That suggestion, to use the Deutsche Nationalbibliothek profiles (or other) to generate redirect titles is an interesting idea, but there are just too many thousands (over 280 thousand?) of redirects, and we need to restrict (remove) to only have the high-use variants. The best place to list numerous variant spellings is within an article's footnotes, and then a wikisearch (Search:[______]) for those rare spellings would match to whichever articles contained them. Meanwhile, we really need a Bot to sift through over 280 thousand current redirects as "improbable redirects" to delete them. For example, a variant of "New York" might include "Newe Yorke" as a reasonable spelling, as stylized from the archaic word "newe" used in other town names; however, some/many people have gone wild and created zillions of bizarre redirects, in the style of "Nuew Yorkke" or "Nue Yorrk" or "Nu.YoRK." or even "N.w Y.rK" or similar bizarro redirects (the mind boggles, see: 65,500 titles in "Category:Redirects from alternative names"). So, in a sane world, then auto-creating historical variant spellings would make sense, but WP is currently overrun, overwhelmed with "redirect hoarding" of certainly many thousands of useless redirects, often many variations of corporation names. However, long-term, perhaps most redirects would be auto-removed unless listed in profiles of variant spellings, so the initial idea might be used, in the future, to prune away thousands of unsourced spellings. -Wikid77 (talk) 01:58, 25 May 2013 (UTC)

Dude, redirects are cheap. I don't see a problem with the proposal, but if one of the alternative titles was already a blue link or redirected somewhere else, this would obviously require human review. Graham87 03:46, 25 May 2013 (UTC)

And it can all go into WikiData. —TheDJ (talk • contribs) 08:19, 25 May 2013 (UTC)

The existence of silly redirects is not an excuse to avoid creating good ones. Creation of good redirects does not depend on the removal of the silly ones, so both tasks can be done concurrently. Note that Wikid77's examples are hypothetical; none of the redirects they mention have ever existed. – PartTimeGnome (talk | contribs) 15:45, 27 May 2013 (UTC)

The best place to list numerous variant spellings is within an article's footnotes, and then a wikisearch (Search:[______]) for those rare spellings would match to whichever articles contained them.

Maybe. But then again, this would be manual labour, too, wouldn't it? The point of my proposal was to do this automatically. --bender235 (talk) 11:42, 25 May 2013 (UTC)

Getting back to the original proposal, this sounds like a great idea for a bot. – PartTimeGnome (talk | contribs) 15:45, 27 May 2013 (UTC)

And if not redirect, it could at least copy the alternative names in the ALTERNATIVE NAMES parameter in {{Persondata}}. --bender235 (talk) 15:08, 1 June 2013 (UTC)

• Just as a (non-technical) comment on this, the 'alternative name forms' in library records are, or at least are supposed to be, only 'forms' that have been 'sourced' from published works (not just random misspellings). The 'possibility' of someone trying to find a WP article from such a source (like, say, a hebrew translation of an american author) seems 'non-negligible'....i.e, this would IMO be a good thing to do 'somehow' from the perspectives of both 'accessibility' and the possiblity of making 'inter-language wiki' links more 'automatically' creatable (especially in the case of 'personal name' records). Revent (talk) 21:04, 1 June 2013 (UTC)

New login and account creation designs being enabled soon

Hi all,

After months of testing, we're finally ready to enable the new designs for account creation and login. We plan on doing this tomorrow (May 29) around 23:00 UTC. If you're intersted in the background, there is documentation about why we did this and how we tested it.

As we announced on the blog a while back, you can try out the new look here before it's launched. (See the blog post for instructions.) If you've logged in or created an account in the last couple weeks, you might have noticed the links we put on the old forms.

Please let me know if you have any questions. We still have some enhancements in the works, but it's long past time these were ready for the primary use cases. Many thanks, Steven Walling (WMF) • talk 01:58, 29 May 2013 (UTC)

This has been  Done now. Steven Walling (WMF) • talk 00:00, 30 May 2013 (UTC)

+1 ·addshore· ^{talk to me!} 11:04, 30 May 2013 (UTC)

• The old login screen was minimalistic and simple to comprehend. It's almost just a simple now, but has a large blue box that looks like it was pirated from Facebook. Necessary? Improvement? Not. -- Ohc ^¡digame!_{¿que pasa?} 06:13, 31 May 2013 (UTC)

• Yeah, I don't like the "Facebookification" either. Huge colorful buttons, flashy pop-ups, "Likes" (the new "Thanks" feature) – I don't know where this will be leading.

The simplistic style of Wikipedia always added to the seriousness an encyclopedia should exhibit. It's getting lost for me lately. Especially since each and every new feature comes with more CSS styling and JavaScript-ing than the one before instead of adapting the current skins ands styles of Wikipedia. --Patrick87 (talk) 08:53, 31 May 2013 (UTC)

I'm gonna start blocking ppl who use the word Facebookification. The only problem here is that people don't want to adjust to change. Be honest about that, don't pretend like the rest of us is trying to imitate Facebook. —TheDJ (talk • contribs) 09:35, 31 May 2013 (UTC)

Change is one thing, but this is something else - and 'Facebookification' is an apt description of what is going on. GiantSnowman 09:43, 31 May 2013 (UTC)

To add to TheDJ: isn't "blocking" a Facebook feature? --Patrick87 (talk) 10:09, 31 May 2013 (UTC)

I wouldn't call it 'Facebookification', perhaps just catching up with what the rest of the web is doing? ·addshore· ^{talk to me!} 13:04, 31 May 2013 (UTC)

It's called Wikiafication, of course. :-) --MZMcBride (talk) 14:00, 31 May 2013 (UTC)

I agree the new login screen is very FaceBookish... Can that be toned down a little... At least pick some different colors or something. As for the Thank feature... Parts of that can be removed with JavaScript (I haven't developed the script to go any further yet)... #A couple technical updates is the discussion for (thank). Technical 13 (talk) 13:29, 31 May 2013 (UTC)

"Facebookification"/"Wikiafication" is not inherently bad. If you want Wikipedia to always look like a Web 1.0 site, archive.org may be just the site for you. But eventually this barebones UI is going to prove insufficient, simply because it will diverge too much from what the normal web user (someone who we'd like to covert to an editor) is used to...hence scaring them away from editing. When this wave of Wikipedians dies off, who's going to be left? No one, unless we learn to accept and prosper from changes like this. Theopolisme (talk) 14:19, 31 May 2013 (UTC)

Theo, since your reply is apparently a reply to me based on the indenting (perhaps you miss-indented?), I'm going to reply to it, and to Edokter below here. I'm all for change and improvement and agree that there is much to do on wikipedia in this regard. I agree with both of you that improvements do need to happen. I'm not sure that a big  FaceBook blue  login button offers any improvement there. All I said is pick a different color. Something that can be unique to Wikipedia, it's not like there aren't 16+ million colors at least to choose from... As far as recruiting goes, I'm still learning the ways of the Wikipedia community despite my adept knowledge when it comes to the actual mechanics of editing. That being said, I'm currently in the process of attempting to put together a "student interest survey" for all of the students of my university (University of Maine System) to see if I can offer a seminar or regular class/meetup or something to inform people more about how Wikipedia works and how they can get involved. I'm documenting everything (and will be reporting when I have something significant to do so on a page in my userspace) so that other senior Wikipedians might be encouraged to try something similar (without having to reinvent the wheel). Anyways, before I get TL;DR, my point was, let's pick a different color scheme for wikipedia than what FaceBook and Twitter and all of the social media sites are doing, please... Technical 13 (talk) 14:42, 31 May 2013 (UTC)

Wasn't supposed to be specifically to you, but your reply was still appreciated--looking forward to hearing about how your Wikipedia meetup works out, please keep me posted (and check out the WP:USEP, even if it doesn't necessarily exactly conform to what you're trying to do) Theopolisme (talk) 14:56, 31 May 2013 (UTC)

If Wikipedia built cars...

Get with the times already. The majority of Wikipedia's user interface is still stuck in the eighties. They're fine for the harcore editors, but a nightmare for new editors. Any change that will take us out of the dark ages is welcome. — Edokter (talk) — 14:23, 31 May 2013 (UTC)

"stuck in the eighties"? isn't this just slightly bit hysteric? can you point to an 80's application similar in any way to wp UI? (it has to be "application" rather than "web site" - there were no web sites in the eighties). personally, i like the recent changes, but we don't have to justify them by declaring the existing system dysfunctional.

the resistance and opposition to the changes is actually somewhat amusing and endearing. we saw similar resistance when "vector" was introduced, and ppl all over the placed declared "monobook" to be the best of god's creations in heaver or on earth, except some digging exposed the fact that (almost identical) opposition, sometime by the same ppl, was shown when monobook was introduced... peace - קיפודנחש (aka kipod) (talk) 14:41, 31 May 2013 (UTC)

Just a thought on that: Books are printed since the 15th century and they look today basically the same as they did back then – because the concept simply works. Transfer of information doesn't need complex styling, actually styling can be detrimental. Wikipedia is an Encyclopedia, and an Encyclopedia was always a book historically! Even if it's an on-line Encyclopedia it still hast the same tasks to fulfill, so why do you think we needed to change fundamental concepts of Wikipedia? --Patrick87 (talk) 15:06, 31 May 2013 (UTC)

True, funny story on that, we were talking to a hostel guest during the recent dev conference, and she didn't even realize the skin had changed over the past 5 years. We actually had to go back and forth between monobook and Vector before she noticed. Then she said: "Oh, yeah the new one is a bit simpler. And that was controversial ??" Oh, and she dropped of her chair when we showed her Visual Editor. I'm pretty sure that fundamentally, she still thought it was an encyclopedia-like resource though. —TheDJ (talk • contribs) 21:47, 31 May 2013 (UTC)

I don't think the objection is to change, per se. The new login form is simply ugly and out-of-place here. The bright green and blue unnecessarily punch the user in the face. --MZMcBride (talk) 15:37, 31 May 2013 (UTC)

I also read some feedback yesterday that telling the user to "Enter your password here" below a field labeled "Password" could be seen as condescending and insulting to the user's intelligence. I suppose I should file a bug about that. --MZMcBride (talk) 15:41, 31 May 2013 (UTC)

Rather than bury my reply further up, I'll try to address the general "why and how" of the design decisions regarding the new forms.

First up: many sites large and small use blue and green as a primary action button color, and we don't intentionally imitate Facebook, Wikia, or any other site in particular in our design work. We use color and size as tools to emphasize primary and secondary actions on an interface, to make it easier to find and take those actions.

The current log in and sign up pages take the basic functionality of the previous versions and build upon them. To validate our design decisions, we tested this style with thousands of new people on the sign up form, gathered feedback in remote usability tests, responded to literally dozens of bug requests and enhancement ideas on Bugzilla, and iterated on these designs many times.

We didn't do this hastily, just to tickle a designer's random fancy, or to imitate Facebook. We did this because, with the gains we saw during testing, this is going to help thousands of additional people join Wikipedia and our other projects every month. Getting new people in the door with minimal pain and confusion is something we owe to those who want to try and improve the encyclopedia by registering. Steven Walling (WMF) • talk 23:15, 31 May 2013 (UTC)

Remember old login-screen was excellent as seen here: I can appreciate all the effort in thinking that the prior login-screen needed work, but it was truly an excellent design, and I need a "thank" button to those who created the old login screen. Before that screen fades from memory, I copied it from Simple Wikipedia, shown below, as one for the history book:

Log in Don't have an account? Create an account. You must have cookies enabled to log in to Wikipedia. Language: Deutsch | English | Esperanto | français | español | italiano | Nederlands            Username: [_________________] Password: [_________________] [_] Remember my login on this browser (for a maximum of 30 days)  Log in   Forgotten your login details?

Sometimes things are not even fully appreciated until they are gone. -Wikid77 (talk) 08:15, 1 June 2013 (UTC)

• One of the things I most enjoy at Wikipedia is the stable environment - the "feel" of the place rarely changes. It feels like home, where even when you wake up in the middle of the night, with the lights out, you can still find your way to the bathroom without bumping into things and waking up the whole household.

This last log-in change was a departure from this norm and should have been better adveritised before it happened, in my opinion. I wonder how many editors did not log-in when they saw this unfamiliar log-in page? XOttawahitech (talk) 22:41, 1 June 2013 (UTC)

In addition to announcements here and on the Wikimedia blog more than a month beforehand, I posted links directly on the old login interface to try the new version, which were live from May 6th until the day of launch. Steven Walling (WMF) • talk 01:50, 2 June 2013 (UTC)

A valid complaint in the past about changes has been that the Foundation didn't announce them well. I don't believe that argument can be validly used in this case. Steven did a good job at trying to announce the new login format and I commend him for this. Killiondude (talk) 01:53, 2 June 2013 (UTC)

Cologne blue moving categories to bottom

Hi, can somebody provide me some coding to put the categories and interwiki links at the bottom of the page, it looks ridiculous for major topics.♦ Dr. ☠ Blofeld 20:00, 31 May 2013 (UTC)

AWB can do that. If you provide a list of articles and place a request, somebody will run AWB on those pages for you. Bgwhite (talk) 22:28, 31 May 2013 (UTC)

The question is not about the wiki source but about the rendered page in the Cologne Blue skin, for example http://en.wiki.x.io/wiki/Wikipedia?useskin=cologneblue. The languages are currently shown at both the top and bottom. At the top they overlap with the sidebar for me in Firefox. The categories are only shown at the top. PrimeHunter (talk) 22:47, 31 May 2013 (UTC)

The following CSS will get rid of the languages from the top, while keeping them at the bottom:

#langlinks { display: none; }

This should reduce the clutter a bit. I'm not sure how to move the categories to the bottom without causing more overlapping, though. – PartTimeGnome (talk | contribs) 01:07, 1 June 2013 (UTC)

It actually looks like a bug, with the links overlapping the sidebar. I submitted a fix —TheDJ (talk • contribs) 09:02, 1 June 2013 (UTC)

Thanks, perhaps the developers would consider changing the format slightly for cologne and placing the language and cats at the bottom? I mean check out United States on Cologne Blue, it just doesn't make sense to have that bloat at the top before an article on what is otherwise probably the nicest looking skin we now have..♦ Dr. ☠ Blofeld 11:10, 1 June 2013 (UTC)

Eh, I think we'd all love to, but there is probably not a single person who would want to burn his fingers on making such a big change to a skin like that, without significant evidence of community support of such a change. We are talking about removing an entire section of the skin, that would be a rare change. —TheDJ (talk • contribs) 19:25, 1 June 2013 (UTC)

this request (i.e., changing it for all cologne users) makes zero sense to me. people who use any skin other than vector usually (though, i would guess, not always) do not want anyone changing anything in the "skin" for them. as to the original question: try and add to Special:MyPage/cologneblue.js the following line:

$( function() { $( '#catlinks' ).appendTo( '#article' ) } );

my minimalistic testing hints that it will do what you want (or at least, what i understood from the request). peace - קיפודנחש (aka kipod) (talk) 01:17, 2 June 2013 (UTC)

Autoblocks

Are autoblocks automatically lifted in the newest version of Mediawiki? I just went to unblock a user, and they automagically disappeared before I had a chance to undo them. Magog the Ogre (t • c) 15:31, 1 June 2013 (UTC)

That is, do they vanish when you unblock the user who was the source of the autoblock? Iirc, yep - User:Coren submitted the necessary patch, actually. Ironholds (talk) 15:35, 1 June 2013 (UTC)

Topics as wp:VPR proposals

To reduce clutter here, while allowing for multi-week discussions, I have submitted some new threads to Village Pump (proposals) wp:VPR:

• wp:VPR#Proposal: Periodically monitor pageview counts
• wp:VPR#Proposal: Move long-term proposals from PUMPTECH to VPR
• wp:VPR#Proposal: Have micro-pages as Micropedia-style articles

There tend to be fewer topics at VPR, so there is less clutter of short-term mixed with long-term issues. I have some other topics to add to that list later. If anyone wants to start a related thread here, that is fine, but I think the topics would be discussed for weeks or months at wp:PROPS. -Wikid77 17:04, 1 June 2013 (UTC)

GFDL relicensing tag

Can we get a bot to go through and substitute the "migration" flag of images with the {{GFDL}} template? Right now, today, if someone uploads a {{GFDL}} image, it shows the {{License migration}} template. Now that it is four years after the license migration, I think it makes sense to change the default to be not eligible for migration. But in order to change the default, we would need a bot to do a one-time addition of something like migration=not-reviewed to all existing uses of the GFDL template. So if you have {{GFDL}} or {{self|GFDL}}, the template would add "migration=not-reviewed" to the template. After that is done, we can make the default "not-eligible" instead of the default being pending review. --B (talk) 00:16, 2 June 2013 (UTC)

Regex and Semitic languages

Moved from Wikipedia talk:Village pump (technical) -- John of Reading (talk) 07:13, 28 May 2013 (UTC)

Hi,

Is that someone understands why the following regex doesn't work fine with right-to-left languages (I use AWB regex):

Find:

\[\[([\w-]+)\]\] \[\[:([a-z]+):\1\|\{\{\2\}\}\]\]

Replace:

{{t+|$2|$1}}

Text to search:

[[משפחה]] [[:he:משפחה|{{HE}}]] [1]

Result:

{{t+|he|משפחה}} [1]

While if I puts in "Text to search" [[test]] [[:he:test|{{HE}}]] [1], the result is fine: {{t+|he|gta}} [1].

Do you understand why?

Thank you in advance to those who will give an explanation for this,

Regards, Automatik (talk) 02:59, 28 May 2013 (UTC)

What exactly are you trying to match? ·Add§hore· ^{Talk To Me!} 10:18, 28 May 2013 (UTC)

funny enough, the result you get is actually the correct result. unfortunately, because of directionality issues with the browser(s), it just does not display correctly. you can see it by forcing the "pre" element to display with "bidi-override". i do apologize for the readers - for most of you this is just mambo-jumbo - i wish it was mambo-jambo to me also... so here is the "same "pre" section as above, with bidi override:

{{t+|he|משפחה}} [1]

peace - קיפודנחש (aka kipod) (talk) 20:54, 28 May 2013 (UTC)

Thanks you both! Actually, it's just the preview is bad, but it works correctly. Thank you again :) Automatik (talk) 14:47, 2 June 2013 (UTC)

Just a question, I tried the replacement here, on the page I see what I want (משפחה (he) [1]), but in the code I see {{t+|he|משפחה}} [1]. It's strange, isn't it? Automatik (talk) 16:03, 2 June 2013 (UTC)

Wiki mark-ups when editing a page, (MediaWiki:Edittools)

I posted the following problem at the WP help desk (but didn't get an answer and redacted):
"Someone seems to play with the way wiki mark-ups are displayed. They used to be click-able but then suddenly they were not and then were again. Now, again, they're not and one has to copy and paste each symbol. Does someone know what's going on here or at which venue this should be addressed? Thanks, TMCk (talk) 03:20, 30 May 2013 (UTC)"
The problem is still going on as it [the click-able mark-ups] are coming and going "on their own terms."
Could somebody please indulge me with what is going on and if there is something I can do to keep the mark-ups click-able? When I occur them in a non-click-able way there is no button to change this unlike when they're blue linked. Appreciated for any helpful response, TMCk (talk) 01:00, 31 May 2013 (UTC)

Sorry, but I think you have to describe more precisely what you are talking about (maybe take a screenshot?). I don't understand your question and others might not understand it either (which could be the reason you didn't receive an answer in the first place). --Patrick87 (talk) 02:23, 31 May 2013 (UTC)

Well, here is another problem I encountered before: I can't upload any file to WP for whatever fucked up reason [a problem I'm not concerned right now]. So here are 2 screenshots taken withing less than a minute of each other from the edit screen of two different pages and uploaded to imageshack: [42] and [43]. Hope this helps pinpoint the problem.
Thanks in front for any helpful response. TMCk (talk) 04:36, 31 May 2013 (UTC)

I'm pretty sure that your original q refers to MediaWiki:Edittools. This depends upon some javascript being retrieved from [Wikimedia's "bits" servers. Several things can stop these links from being clickable: (i) your browser doesn't support javascript; (ii) it does support javascript but it's been disabled; (iii) you have a slow network or slow internet; (iv) the Wikimedia bits servers are slow. Of these, the first two are unlikely, given what you've already stated about it working sometimes. The other two have a similar effect: after a period, your browser "times out" - it gives up waiting for all of the javascript, and displays the fallback "Copy and paste" text instead. I'd try to establish that you do have a good connection, and if so, blame the Wikimedia servers. --Redrose64 (talk) 08:50, 31 May 2013 (UTC)

Between iii and iv, I'd add "The connection between you and Wikipedia is bad". It is quite distinct situation from iii and iv, quite common and probably the hardest to test for normal users, with a lot of possible causes. —TheDJ (talk • contribs) 11:29, 31 May 2013 (UTC)

Thanks for the input so far. Here some facts/info in response:
Indeed, Java script shouldn't be the problem as the named edit tools worked just fine before. I just checked on another faster/newer/better computer (laptop) and get the same problem. for month I used to get a message of a script running slow and recommendation to cancel (the script) as the system might stop responding. I stopped the script and usually something was was not working which was of course logic. Now, for whatever reason, I rarely get this warning even on large pages with lots of templates. I also do not get timeout messages or anything alike and the edit tools might or might not pop up even on small and simple pages that load within seconds. My "real" internet speed is around 3 Mb/s so that shouldn't be the problem either, at least from my side.
Ergo, I can for sure blame it on Wiki and my good guess is that someone screwed up, again. Wikid77 makes a good point below as I had just as many others plenty of problems when they implemented the new notification system full of bugs.
Again, thanks for all the helpful replies so far. They made clear [I know I repeat myself here in part] that all I can do is having more-more-and-even-more patience and hope they'll fix the problem at some point.TMCk (talk) 23:31, 31 May 2013 (UTC)

Wikipedia is very reliant on caching of pages and scripts (much more than most websites). It might be that your ISP or your home router is using some sort of proxy caching that is operating faulty. I'm not sure where you are located, but in many areas of the world ISPs do a lot of caching to speed up your internet connection and to save bandwidth for themselves. If this caching is a tad lazy (inherently making it broken), it might be serving you 'stale' pages. Pages/scripts that are outdated and really should be fetched from Wikipedia again (because they would have different contents), but instead you are getting from a cache somewhere. This should not happen, it's a bug, but not one you (or Wikipedia) can do a lot about (the helpdesk will loose you after the first sentence). Usually these pages are cached for about 30 days maximum, and then it's should clear up. If you really want to know, then you need to do problem reduction. Try your computer at someone's house with the same ISP, try at someone with a different ISP, try changing your router brand etc. you need to separate all potential problem areas, and reduce the 'surface' of where the problems occur. That way you could reduce it to a pc, a router, your isp, your region etc. Remember that ISPs often have multiple brands, take that into account as well. Its cumbersome work and not what you want to hear, but there is not much that other editors can do to help you. I've checked your account, and you are not running any custom scripts. There haven't been reports about malfunctioning gadgets (at least none that aren't resolved). However there was a big breakage in the gadgets and scripts last week. If your ISP is caching the broken state of one of those scripts, it might explain why you cannot get it fixed. —TheDJ (talk • contribs) 12:12, 2 June 2013 (UTC)

• English WP website has descended into total chaos of bizarre changes: During May 2013, the MediaWiki software has been changed, every few days, to add new features, and drop others, such as the orange new-messages bar. The typical bottom box of accented letters/symbols is gone at times, but essay wp:PASTE shows those symbols to copy/paste as in foreign languages. Keep a copy of pages saved offline as backup, and expect to get "Cannot find server" at times. There is a recent petition to protest the rampant peculiar changes to the MediaWiki software, as listed above in the VPT infobox (at top):

• WP:Petition to the WMF on handling of interface changes

Meanwhile, some edits can be tested by copy/paste into Simple Wikipedia or German Wikipedia, which have not been fully derailed yet. A few people have called for the firing of WMF personnel, but I ask people to realize the developers are capable people and can be directed to restore the prior website software, and delay future disruptive changes. We have seen no evidence of corrupted page contents, but menus and headers might appear garbled. -Wikid77 (talk) 06:03, 31 May 2013 (UTC)

Wikid77. You pinpointed an ongoing problem. I fully agree and will also sign the petition shortly. I too wouldn't call for "firing of WMF personnel", although when (programming) geniuses are blowing up the barn they need some serious supervision.TMCk (talk) 23:31, 31 May 2013 (UTC)

• The problems are actually supervised: We will need to contact the WMF managers to change directions; for typical software development in U.S. firms, those kinds of changes being made, with wp:Notifications and Thanks-buttons, require budget allocation and approved design plans, directing the efforts of "(programming) geniuses" to perform very disruptive actions, such as re-changing menu navigational controls ("don't keep moving the car's brake pedal") and putting numerous buttons "(thanks)" where they are likely to be accidentally clicked, causing a future psychological aversion to "(thanks)" as marked with unpleasant side-effects. The ergonomics of WP screens need to be re-considered, and contacting supervisors is the fastest method, as with the user-interface petition. I have advised to hold "WP screen-design competitions" to get massive improvements in screen designs rather than disrupting menus for trivial changes. When changing the user-interface buttons, make sure the shifts are worth the shock, and get buy-in from many users. -Wikid77 (talk) 01:27, 1 June 2013 (UTC)

• Do you have any evidence whatsoever that any of the problems reported are due to the projects you're soapboxing about? Ironholds (talk) 04:05, 1 June 2013 (UTC)

You pop up suddenly when there is some constructive criticism about developers but you fail to give a useful response to what this thread is about? If you're involved in the problem described it would be nice to give a useful answer about the issue and how you'll work on a solution rather than just being, apparently, offended (for what reason?) and place a real offensive and useless comment.TMCk (talk) 05:26, 1 June 2013 (UTC)

Wow, apparently ppl aren't allowed to popup anymore. And you wonder why ppl find en.wp such an unkind place that they'd rather avoid. —TheDJ (talk • contribs) 09:22, 1 June 2013 (UTC)

I'm popping up as a volunteer, not a staffer. And, no, I'm not responding to constructive criticism, and I'm not offended; I'm annoyed. Big difference. Here's why I'm annoyed; you have reported that you, as an individual, are struggling to load edit tools and upload images. This is not, to my knowledge, something that has been replicated anywhere else - of our half-billion users and N thousand editors, you are the only one who has come up with the problem, which is something that, as TheDJ has pointed out above, can be explained by many factors that have nothing to do with the servers. And your instinctive response is to blame the developers, based on zero evidence that the problem is at the server end. Iff it is a problem at the server end (and if it was, again, you'd expect other people to notice or report it), the people who would fix it are almost certainly nothing to do with the teams working on Echo or any of the other projects you're also taking issue with. I find this attitude - to instinctively blame the WMF when anything goes wrong - to be problematic, yes. Ironholds (talk) 12:54, 1 June 2013 (UTC)

This is in response to the above and posts you made on related talkpages.
Youre popping up as a "volunter" to comment on an editor's comment accusing him of "soapboxing", yet according to your user page you're working in real live for the Wikimedia Foundation "building new software". You also were involved in the new notification system (ECHO) that was introduced with many bugs and little to no input from regular editors who don't pay much attention to such, (when editors do have problems with changes they might not care enough or simply don't know where to comment, so the number of affected users is of course way higher than can be seen.) The RFC regarding the forced upon change made the change to a small orange bar happen and after several complains of bugs in the system they were fixed after some time. Something that shouldn't have happened as the new feauture should've be inplemented only after making sure there are no (big) bugs left and some short trials, (besides better communication with the community if and what they really want.)
You say you're "annoyed" and "...find [my] attitude - to instinctively blame the WMF when anything goes wrong - to be problematic". Re-read the thread and you'll find that after going to the responses made I pinpointed the problem to WP after checking on and ruling out every other potential problem that was posted. So no, it wasn't anywhere near of "blaming the WMF as default".
I admit that my temper runs higher than usual since the (now solved) ECHO fiasco and I appollogize for it. Maybe you should too, for your post that started IMO to derail this discussion (with me too being to blame.)
Anyhow, since you appear to be an expert according to your user page I gladly would take up your offer (you made somewhere regarding this) and continue our conversation at your talkpage, with concentrating on technical issues you might be able to solve for/with me on way or another. If you'd like to do so please just start posting a thread with infos or questions for info you need from me to get to the grounds of the problem. BTW, while editing this the mark-ups (MediaWiki:Edittools) works again just fine. Thanks in front for further input, TMCk (talk) 22:03, 1 June 2013 (UTC)
Note: Now the mark-ups are again just copy and paste so it still keeps switching.TMCk (talk) 22:07, 1 June 2013 (UTC)

When I say I'm popping up 'as a volunteer' I mean that I'm here in my personal capacity, not in my professional; I'm not denying working for the Foundation. Yes, I help build new software; no, I'm not a developer. Yes, I was involved in Echo; no, I'm not involved in this bug. In regards to Echo's bugs, Echo was extensively tested, but there isn't a prototype instance in the world that compares to actually deploying it and having tens of thousands of editors troop through its workflows. No software is bug free in version 1.0, and no software can be until it's fully exposed to the user base.

In regards to the specific bug; stick a bug in bugzilla. Explain what's happening, give your browser and operating system, and hopefully someone will get to it. If it is a problem at the server end (and that's far from confirmed) it's one effecting a tiny, tiny number of users, so it's no surprise it hasn't been detected until now. Ironholds (talk) 23:05, 1 June 2013 (UTC)

Please forget about all the "other" stuff that is in the past by now. I ask you again: Would you be willing as you offered in another thread to help me out with the weird problem I encounter for a week or so? I'd be much appreciated to engage in a constructive conversation about this at your talk page. If you'd like to take your offer back or I have misinterpreted said offer please just say so. I truly would like to leave non-constructive remarks/comments be bygones and start fresh at either your or my talk page, find out the problem and see if there is a solution. There is really no need for any further defensive posts. You made you point quite clear already. I'm still trying to get some help solving the problem I have, no matter if I'm the only one or not.TMCk (talk) 00:15, 2 June 2013 (UTC)

For the record, I have the same problem with the Edittools only loading the fallback from time to time and it usually corresponds with others noting Wikibits on the fritz or an error in a javascript I am working on or one that I have loaded that someone else is working on... Usually, going to get a drink, coming back, and reloading the page fixes it... Also, can we please try to assume a little more good faith and stop flaming the WMF lackeys so much, it is counter-productive and quite frankly getting annoying. Thanks, I appreciate that so much because I know you just said, "sure, I suppose you're right, it isn't gaining anything". Happy editing! Technical 13 (talk) 12:19, 2 June 2013 (UTC)

How to run a query about user contributions - help needed

I am intending to carry out a research following the 2011 Former Contributors Survey Results (WMF is aware and supportive of this project, which we hope will provide WMF and the community with useful information about editor retention; and I am a Wikipedia studies scholar with a track record of peer reviewed publications). A major part of this project involves studying the contribution patterns of most active editors; I am in particular interested if there is a correlation between contribution to certain namespaces/pages within them and editors becoming less active and/or leaving our project altogether.

However, doing this using the Special:Contribs is painful, verging on impossible due to being way too time consuming, particularly with the requests timing out 9 times out of 10 (and I am trying to create a dataset for edits of 1,000 or so editors). None of the tools listed at Wikipedia:WikiProject edit counters which I have used in the past have the functionality or speed I require.

At the same time I am pretty sure this can be done by individuals who have the voodoo knowledge required to use Wikipedia:Database queries; unfortunately I am not capable of doing so. To be honest, I am not even capable of carrying out the instructions at Wikipedia:Database_queries#Requesting_that_a_query_be_run; I have created an account on the toolserv but its interface is too unfriendly for non-CS person like myself to even be able to file a request there. Smirk if you will, I am a social scientist, my coding knowledge ends at wiki syntax, and the most technical place I can ask for help is here.

Therefore I am looking for help: I require an assistance from someone who can help me run some queries on the database. To be specific with regards to what I need, I have a sample of editors (based on Wikipedia:List of Wikipedians by number of edits) and I'd like to get numbers about their contribution to specific pages, such as WP:AN or WP:AE. As you can see, all the data I am looking for is publicly available; my problem is that I don't know how to make it machine-readable (i.e. create a .csv file or similar, so that I could run some queries of my own in statistical software such as SPSS). Ideally, the results would be distributed by each user on a time scale (monthly or daily), and paired with their total number of edits (so, saying for each editor in the sample that for month X that editor had X edits to AN, Y edits to..., and so on, within Z edits total). I know we have/had edit counters that could do this by namespace, so I am pretty sure this could be doable for individual pages or sets, too.

Please note that I can cover expenses required in obtaining this data from my research budget (in other words, I can pay for your time, or alternatively, I'd be happy to donate $$ from that budget to WMF, or help you get an article to a Good status, or write a DYK on a topic of your choice...).

Even if you cannot help me with all I am asking here, any advice would be appreciated (as in, if someone can point me to a specific downloadable (?) dataset that contains data I need, it may be easier for me t find somebody who can work on it but cannot find it, and so on). --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 11:47, 1 June 2013 (UTC)

@Piotrus:: You may find the user contribution search tool useful, but even it may not be powerful enough for your purposes. Perhaps it would be worth talking to the maintainer of that tool (and others like it), Scottywong. Graham87 16:39, 2 June 2013 (UTC)

@Piotrus: (Meatsock) User:Betacommand has offered to help. He can be contacted at betacommandtoolserver.org 930913(Congratulate) 17:00, 2 June 2013 (UTC)

Thank you for the pings and offers to help! --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 02:33, 3 June 2013 (UTC)

Top edited pages

Going from this page, I have decided, out of mere curiosity, to create the page User:Toccata quarta/EditCounterOptIn.js. But when I'm about to do that, I get a warning stating "Code that you insert on this page could contain malicious content capable of compromising your account." My question is: how can I know if what I'm going to enter into the page might compromise my account? And moreover, what kind of content should I place into the page? Pressing "Save page" without doing anything else brings no result. Thank you in advance. Toccata quarta (talk) 17:37, 2 June 2013 (UTC)

• You're totally fine. JavaScript can do some bad things, if you code it right (wrong?), but you don't even have to have any actual JavaScript in that page. See, for example, my opt-in page. Ignatzmice•talk 17:41, 2 June 2013 (UTC)

Does that mean that the list of top edited pages will become available at tools.wmflabs.org if I enter a mere period? Toccata quarta (talk) 17:46, 2 June 2013 (UTC)

Indeed. I'm not the one who wrote it, but it certainly seems that all the tool does is check for the existence of that page (with any content). A period would be fine. Ignatzmice•talk 17:52, 2 June 2013 (UTC)

Thank you for your help—I have created the page now. Toccata quarta (talk) 18:02, 2 June 2013 (UTC)

Proposal: mark default gadget as "default"

So the "gadgets" extension (mw:Extension:gadgets) allows defining some of the gadgets as "default". these gadgets are active for anons and new users, though the latter can, of course, turn them off. it is not exrtemely difficult to find out which gadgets are "default" - one has to peek in MediaWiki:Gadgets-definition, and look for "default". however, it is often times very useful to know which gadgets are on by default: e.g., when explaining things to other users (esp. new or inexperienced users), one can assume ("by default") that the default gadgets are active for them. it would also be nice to have some idea which gadgets will be active if one presses the "Restore all default settings".

i propose to mark all the default gadgets in "Preferences => Gadgets" page, by adding a tiny suffix to the lines describing default gadgets, that looks like so (without the quotes): " (default) ". peace - קיפודנחש (aka kipod) (talk) 22:39, 28 May 2013 (UTC)

Support:  Technical 13 (talk) gives his support for this section's subject at 22:57, 28 May 2013 (UTC).

Actually this is already done on Commons. I think it's a good idea, especially for beginners who are not aware of MediaWiki:Gadgets-definition. However we should probably use an unified way to mark Gadgets across projects. What you are proposing is already differing from Commons. I'm not saying Common uses the best solution but at least it looks already quite good to me. --Patrick87 (talk) 23:34, 28 May 2013 (UTC)

actually, commons is where i picked up this idea in the first place, and i should have mentioned it in the proposal.

it's not critical how exactly is the "defaultness" of a gadget is represented visually, as long as it's available.

personally, i'm not so keen about the way this was implemented in commons: i'm not talking about the visual part, but rather about the actual implementation: in commons, there is one template, called commons:Template:Gadget-state, which maintains a list of all default gadgets. when someone changes the "defaultness" of any specific gadget, they need to edit this template also. but regardless of the way this information is presented visually, and regardless of the way this is implemented, i still think it will be good to have this information available _somehow_. peace - קיפודנחש (aka kipod) (talk) 13:05, 29 May 2013 (UTC)

Related: bugzilla:34522. --MZMcBride (talk) 20:52, 30 May 2013 (UTC)

Marking ALL the Special:Preferences defaults, on every tab, would be helpful. There's the "Restore all default settings" button of doom which wipes out all our customizations, but often I'll want to make sure that I'm seeing a page the way most other editors do, eg thumbnail size defaults (What are they currently? 220px?). I know I've changed a few options at Special:Preferences#mw-prefsection-editing, but I'm not sure which...

A few defaults are mentioned in the page itself, and a few are mentioned at Help:Preferences and mw:Help:Preferences, but not all. It would be best if they were all marked within the Special:Preferences page/tabs itself.

As for how to mark the defaults - There's the marker "(default)" as suggested by קיפודנחש above, which is possibly the best method. The only other simple standard I can think of, is that used by [about:config] in mozilla projects, where user-customized items are marked in bold (but that would probably be a lot more complicated to implement). Any other ways? –Quiddity (talk) 23:44, 3 June 2013 (UTC)

Spam

I have several hundred thousand edits on wikipedia, my own wikis, and mediawiki sites. I feel the biggest weakness of mediawiki is the spam. Sites like wikipedia and wikia with huge number of technical people stop this spam, but little sites like some of mine are overwhelmed.

A couple of questions:

1. Is there plans to have spam programs like CAPTCHA already installed in future versions of mediawiki?
2. How do I get rid of spambots editing pages on my wiki? I already have Extension:ConfirmEdit with QuestyCaptcha (I was unable to successfully install any others). These spambots are able to create accounts, but they cannot edit.

Thank you! Igottheconch (talk) 14:56, 29 May 2013 (UTC)

See mw:Manual:Combating_spam and mw:Extension:AbuseFilter Werieth (talk) 15:00, 29 May 2013 (UTC)

on my wiki, i had huge spam problem, until i installed mw:Extension:ConfirmEdit. i do not use any visual captcha, but rather "confirmcaptch": users are asked to answer a question in order to register. anons can still post, but if they try to add any link, they are required to answer the question also. so far (~2 years) this have stopped the spam entirely (knock on wood, i hope this won't change). this would not work for large enough or "interesting" enough wikis: spambot operators can, theoretically, teach their bots to answer the question, but if your wiki is small enough/obscure enough, this will never happen in practice. peace - קיפודנחש (aka kipod) (talk) 16:03, 29 May 2013 (UTC)

See also Bayesan spam filter, which is being worked on at Google Summer of Code, for Wikimedia. It will be primarily useful for small wikis.--Snaevar (talk) 01:51, 30 May 2013 (UTC)

thank you so much guys! Your the greatest. Snaevar, Bayesan spam filter sounds promising!

קיפודנחש (aka kipod) As I wrote above (modified to explain what I was trying to say):

I already have Extension:ConfirmEdit with QuestyCaptcha (I was unable to successfully install any others). These spambots are able to create accounts, but they cannot edit.

Here is the section of my localsettings:

require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" ); require_once("$IP/extensions/QuickLink/QuickLink.php"); require_once( "$IP/extensions/ConfirmEdit/QuestyCaptcha.php"); $wgCaptchaClass = 'QuestyCaptcha'; $wgCaptchaQuestions[] = array( 'question' => "What month did the terrorists attack the world trade center?", 'answer' => "September" ); $wgCaptchaQuestions[] = array( 'question' => "What country does chinese food come from?", 'answer' => "China" ); $wgCaptchaQuestions[] = array( 'question' => "What month comes after June?", 'answer' => "July" ); $wgCaptchaTriggers['edit'] = true; $wgCaptchaTriggers['create'] = true; $wgCaptchaTriggers['addurl'] = true; $wgCaptchaTriggers['createaccount'] = true; $wgCaptchaTriggers['badlogin'] = true; ##$wgGroupPermissions['*']['skipcaptcha'] = false; ##$wgGroupPermissions['autoconfirmed']['skipcaptcha'] = true; ##$wgGroupPermissions['bot' ]['skipcaptcha'] = true; // registered bots ##$wgGroupPermissions['sysop' ]['skipcaptcha'] = true; ##$wgGroupPermissions['emailconfirmed']['skipcaptcha'] = true; ##$ceAllowConfirmedEmail = true; ##captcha settings end

Again, the QuestyCaptcha questions successfully STOP the spambots from editing pages (Every couple of months I have to change the questions), but they still can create user accounts, dozens everyday.

For some reason the spambots are still able to create accounts. I am not sure how or why! Igottheconch 04:52, 30 May 2013 (UTC)

this looks strange: if they can indeed create, why don't they post their junk like they did before? did you try to create a new user account on your wiki yourself, and verified that it's not possible without actually answering the question? peace - קיפודנחש (aka kipod) (talk) 14:29, 30 May 2013 (UTC)

yes it is very strange. I tried creating a new account and I had to enter the captcha, somehow spambots are able to circumvent the captcha.

Screenshot of the 200+ spambots which registered in one day.

Screen shot of failure to create an account without entering question captcha.

Could spambots somehow create an account with Manual:Parameters_to_index.php, circumventing the captcha?

I just added $wgGroupPermissions['*']['createaccount'] = false; to localsettings, the new account creation is getting out of hand.

Igottheconch (talk) 03:37, 31 May 2013 (UTC)

Any other suggestions on what I can do to stop spambots from creating new accounts? What does wikipedia do? Igottheconch (talk) 14:41, 3 June 2013 (UTC)

Problem with flagicon of Switzerland

Proposal: Template_talk:Flag#Fix Swiss/Nepal/Vatican flag height.

Please tell me, which size of Switzerland flag is correct in comparison with the "normal" 2:3 flag. I guess it's the smaller one. But in Wikipedia tables is that bigger one as default and it looks ugly (I mean unequal height of lines). 195.91.108.91 (talk) 22:52, 30 May 2013 (UTC)

{{CHE}} uses 17px. -Wikid77 11:48, 3 June 2013 (UTC)

• Perhaps use medium size 17px for Switzerland flag-size problem: Thanks for reminding people about the unresolved flag-size problem for Flag of Switzerland, which has caused line-height trouble for years. After all this time, I would use medium size, x17px, as a compromise between typical x20px width and typical 15px height of the 2:3 ratio flags (re Italy): so x17px versus x15px: . Although WP has the wp:IAR to ignore rules that prevent improvement, or hinder better typesetting, I suggest to compromise between the common "x20px" Swiss-flag height and the smaller 2:3 ratio x15px height, as the middle ground with x17px. In lists with smaller-font text, then consider x16px, or even x15px, when a better fit. However, you might meet severe resistance from flag advocates, so remind them of the technical advantages with a medium-size compromise, to fit within line height but more visible than a 15px height. Any other questions? -Wikid77 (talk) 03:52, 31 May 2013 (UTC)

In Template:Flagicon is the icon size currently set to 22×20 pixels. Maybe would be enough to set it to 22×15 pix as default, instead of manual editing of every article. 195.91.108.10 (talk) 10:12, 31 May 2013 (UTC)

• See talk-page to reduce Swiss flag icon: I have restarted the discussion from 2 years ago, as: "Template_talk:Country data Switzerland#Reduce default size" and wider discussion:
  "Template_talk:Flag#Fix Swiss/Nepal/Vatican flag height" to fix Nepal/Vatican also -Wikid77 00:46, 1 June, 11:48, 3 June 2013 (UTC)

Toolserver issues

Why is the Toolserver not loading? For almost two weeks now I have gotten "Connection reset" messages when trying to access it. Is it really this bad off? --Nathan2055^{talk - contribs} 16:32, 31 May 2013 (UTC)

Maybe just your account / browser? It has been working fine for me (minus the occasional and scary 'This user does not exist on en.wikipedia'!) GiantSnowman 16:35, 31 May 2013 (UTC)

The toolserver has not been working properly for months. Please see other threads on this page and in the archives. --Redrose64 (talk) 16:41, 31 May 2013 (UTC)

It's gotten to the point for me that the 20% of the time that toolserver works, it takes pages almost 10 minutes to load for me... It seems to have been abandoned already despite the fact that the memo said 2014... Technical 13 (talk) 16:49, 31 May 2013 (UTC)

The toolserver is a perfect example of exactly the type of problem we should be addressing, not all these stupid facebook facelift changes. We need to put time and effort into areas that will improve things, not in areas were it might, or just because we feel like it. Kumioko (talk) 16:55, 31 May 2013 (UTC)

The Toolserver is being addressed: Labs will replace it by the end of 2013. Already, many tool authors (including myself) have begun migrating their tools to the more stable Labs environment. I don't want to get into the politics behind the migration (the toolserver mailing list archives are quite revealing, if that's your kind of thing). Also, GiantSnowman: X!'s edit counter, btw, is currently being migrated by TParis and cyberpower678. Links on-wiki will be updated when that move is complete...those errors should go away :) Theopolisme (talk) 17:07, 31 May 2013 (UTC)

Thanks, yeah I was aware it was being addressed but my point was that we basically let the toolserver get to a state of collapse before we did anything about it and now we are having to struggle through several months of problems before its fixed. Assuming the replacement isn't delayed. It was just one example anyway. There are long lists of other things that IMO should have taken precedance over these types of changes. With that said, I have advocated for some time that the WMF needs to step up and do some of these things (technical and nontechnical) because the community has shown repeatedly we are incapable of doing them ourselves. So I admit its a bit hypocritical of me to say they need to step up and make the changes we can't but then criticize them when they do. When they do unwanted and unsolicated changes like these lately that also don't work and aren't particularly beneficial, it doesn't really reflect positively on them that their decision making skills are any better than ours. Kumioko (talk) 17:53, 31 May 2013 (UTC)

Migration of the edit counter and the very popular adminstats will need to wait another few weeks unfortunately. There are some tables that are not yet accessible on labs. We are preping the counter for labs though at this time.—cyberpower ^Chat_Offline 18:17, 31 May 2013 (UTC)

Edit counter now not working? GiantSnowman 19:32, 31 May 2013 (UTC)

Like everything else on Toolserver, you can expect it to come and go at irregular unpredictable intervals. If you try again every hour or so, you might find that it works as it should. --Redrose64 (talk) 22:41, 31 May 2013 (UTC)

I broke all my tools accidently right before the wife shuffled me out the door for a dinner date with friends. So I cant fix them until I get home.--v/r - TP 23:26, 31 May 2013 (UTC)

Like'·addshore·' ^{talk to me!} 08:27, 1 June 2013 (UTC)

↑ Do you do this on purpose? I hate it (as I hate Facebook) and I really hate to see it on Wikipedia! And it just accelerates "Facebookification we were talking about above in #New login and account creation designs being enabled soon. --Patrick87 (talk) 14:05, 1 June 2013 (UTC)

Sorry, not on purpose! Maybe we should create our own special wiki symbol to use? :D ·addshore· ^{talk to me!} 20:29, 1 June 2013 (UTC)

 Brilliant idea! Patrick87 WikiloveS this idea! +

Whatever — as long as were not continuing to copy symbols from other communities. I like the Wiki community for not being the same like the others. I hope this will stay this way. --Patrick87 (talk) 22:04, 1 June 2013 (UTC)

Like What Patrick87 said! We should +1 Gogglefy instead! Technical 13 (talk) 16:30, 1 June 2013 (UTC)

Back to the edit count, mine hasn't been working for a full day now. Lova Falk talk 14:53, 1 June 2013 (UTC)

Yes, I’m getting 404 errors from the link at the bottom of Contributions.—Odysseus1479 20:21, 1 June 2013 (UTC)

Last I heard people were working on moving this to tool labs (and I heard this about 30 mins ago). I imagine all of the links will change once it gets set up :) ·addshore· ^{talk to me!} 20:27, 1 June 2013 (UTC)

http://tools.wmflabs.org/xtools/pcount/ now.—cyberpower ^Chat_Online 21:57, 1 June 2013 (UTC)

I expect you know all about this, but: It's not counting my deleted edits (of which there should be many, due to CSD tagging). Ignatzmice•talk 22:02, 1 June 2013 (UTC)

Same here, deleted edits: 0 - which isn't true. But the edit count is working again, which is good. Lova Falk talk 06:25, 2 June 2013 (UTC)

Yeah, I came here too just to say that my 2,000+ deleted edits has been reset to 0. Cool! Jared Preston (talk) 07:56, 2 June 2013 (UTC)

Ah, what I didn't notice is that the deleted edits have been subtracted from my total number of edits. So just for your information, instead of 43k edits, I now have 41k edits, acc. to the tool. Jared Preston (talk) 08:06, 2 June 2013 (UTC)

• Sorry guys. I forgot to mention that the labs does not yet allow us to access the deleted edits table list. That means it can't count deleted edits at the momemt. Coren has assured us that he's working on it.—cyberpower ^Chat_Offline 10:36, 2 June 2013 (UTC)

  Oh and I just brought back the articles created counter. http://tools.wmflabs.org/xtools/pages —cyberpower ^Chat_Offline 10:38, 2 June 2013 (UTC)

  So are these two new links going to be permanent? GiantSnowman 10:42, 2 June 2013 (UTC)

  For me it returned a blank page after about five seconds (Try it). I have made a lot of edits, though. -- John of Reading (talk) 10:46, 2 June 2013 (UTC)

  Edit counter is fine to me, loaded straight away - but the article creator counter took about 5 minutes to bring back a '502 Proxy Error'. GiantSnowman 10:49, 2 June 2013 (UTC)

• Hey guys. I'm most active at #xlabs ^connect. That's our official channel for these tools. It helps a lot to report the bugs there. The bug reports link also directs to there now. I will also look into the bugs me tipned here when I get home from work today.—cyberpower ^Chat_Online 15:12, 2 June 2013 (UTC)
• Edit counter bug fixed. Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 93 bytes) Since we are on labs, we can of course use more resources so I have enabled top edits for users that have more than 75,000 edits now but less than 500,000. I forgot to expanded the memory limit.—cyberpower ^Chat_Online 21:04, 2 June 2013 (UTC)

For general information on Toolserver and Labs also see http://www.mediawiki.org/wiki/Wikimedia_Labs/Migration_of_Toolserver_tools and http://www.mediawiki.org/wiki/Wikimedia_Labs/Toolserver_features_needed_in_Tool_Labs for general information on the plans and status. --AKlapper (WMF) (talk) 09:22, 3 June 2013 (UTC)

• See also Wikipedia:Wikimedia Labs which has some helpful information and links. 64.40.54.184 (talk) 02:09, 4 June 2013 (UTC)

Message for globally-locked

I just now went to block a spammer, but didn't because the system gave me a "The user Tujtatimento is already locked globally" message. Is this a new feature, or I have I just not seen it before? Nyttend (talk) 12:52, 2 June 2013 (UTC)

It's been around since at least October 2008]. You may recall this amusing accident that occurred thanks to that feature. Graham87 15:25, 2 June 2013 (UTC)

No, I'm sorry, I'm not asking about global locks — I was only asking about how Special:Block gives a message talking about the lock. But yes, I remember the incident; I pointed someone to this specific link a few days ago :-) Nyttend (talk) 16:56, 2 June 2013 (UTC)

I think you just missed it, its been around for a while. Most likely its since most of the time we don't bother to block globally locked users. In some cases it can be useful since it will trigger a local autoblock too. Legoktm (talk) 20:55, 3 June 2013 (UTC)

The Athena Skin

Interesting ... Has this been announced anywhere and I've missed it?--Gilderien Chat|List of good deeds 13:20, 2 June 2013 (UTC)

*Shudder*, and also the mediawiki page on it: mw:Athena. Both from a while ago, no idea what the current progress is on it. - Kingpin¹³ (talk) 13:40, 2 June 2013 (UTC)

As I commented in the Concerns with Flow discussion above it seems like the WMF is set on changing Wikipedia to be prettier and try and attract new users but basically stating the hell with those of us that already edit. The WMF has in multiple occasions said that editor retention is not a priority which, IMO is a large part the problem with why editors don't stay. Is true that some leave because it takes a while to learn the rules of the site but its more of a cultural problem with the community than a technical problem. The reason they leave is because a lot of folks in the community treat new editors like shit and block them or badger them before they have a chance to learn the policies. The policies are what makes the site hard, not learning to indent comments on talk pages with a colon or learning a little Wikimarkup or HTML. If we fix those cultural issues then we will start seeing improvements in editor retention both in longterm editors but new ones as well. Kumioko (talk) 14:34, 2 June 2013 (UTC)

Kumioko, as TheDJ says below, Athena is primarily a thought experiment. There are some elements we're working on, like having consistency in what bits of the UI are coloured what, but it was mostly an exercise in "what might Wikipedia need to look like in 5/10/20 years". Most things on MediaWiki.org are not things we plan to deploy, and I'm disappointed to see you launch into a schpiel from what is ultimately a misunderstanding - particularly one that argues we don't think editor retention is a priority. Can you please point me to any Foundation statement to that effect? Okeyes (WMF) (talk) 16:56, 2 June 2013 (UTC)

Okeyes, I think you are taking more offense at my comments than is intended. There just comments in a discussion voicing my concerns about comments that have been made and actions that are being taken. No offense is directed at you or the other individual members of the WMF. I'm not "Launching off" into a discussion. I am commenting in a discussion someone else created. You need to see things from my/our point of view though. There were recently several changes made to the site that were not an improvement, caused a lot of irritation and were generally not worth the time spent. Additionally, the WMF has stated in the past and generally has the attitude that they need not discuss changes to the software with the community nor ask our permission to implement them. If that offends you that I bring that up, then that's fine. I'm not the one that said it. I'm just repeating what the WMF has said in the past. Software development and maintenance of the iste is their domain. Site policy and updates to content for the most part are up to the community. I'm not going to go searching for diffs because its pretty common knowledge. I think you mentioned something like this before yourself. I also agree that there needs to be some design changes. But we are not facebook, we do not need to copy facebook; or twitter; or anything else. Its ok for us to have our own look. We need to design smart chanegs. Not copying and implementing Facebook functionality (and please dear god don't implement a Timeline CSS skin). I also know that Athena ended up as a thought experiment. But that is not how it started. It morphed into a thought experiment because some of us saw flaws in the methodolgy and assumptions being made with its development. Many of which are still applicable to Flow BTW. I would add too that Flow could work for a lot of Wiki's. Particularly those that are not template dependant. It could be one of those options in Mediawiki that doesn't get deployed here. That would be ok too. No one is saying that it can't be. But all evidence points to that it is going to be "forced" on us at some point in the future hell or high water so if that is to happen, I wanted to voice my conerns in the hopes that they are considered. I can't make you or anyone else do anything. But I have offered my comments and voiced my concerns. Its up to you whether you want to take me seriously or just ignore my comments and do whatever you want to do. Kumioko (talk) 15:00, 3 June 2013 (UTC)

Athena was sort of a thought experiment. Some of it's ideas have gone into the mobile skin, some led to echo, some are part of Flow, etc. —TheDJ (talk • contribs) 16:24, 2 June 2013 (UTC)

• Growing support for participatory design: I agree we should move to "Participatory design" but also just here on Wikipedia, without trying to talk with WMF employees (re: "You can't fight city hall"). We have enough numerous experienced editors who could create some "recommended" skin variations by resetting either CSS or JavaScript interfaces. This does not require developers, except to the extent that they do not botch the basic support for CSS and JavaScript to function. I have begun to design some new screens for Wikipedia, based on how an experienced computer scientist would format the screens, and then we could get many people to suggest other major ideas, not just shift menu options up/down and collapse. -Wikid77 (talk) 14:08, 3 June 2013 (UTC)
  • Heh, I think that most of Wikipedia's interface problems derive from being designed the way an experienced computer scientist would design them; all function, no form, everything geared toward the power-user, no thought given to the newbie. Writ Keeper ⚇♔ 14:15, 3 June 2013 (UTC)
  • You should have mentioned redesign for newbies years ago; a good solution is to have a Help-button on the screen, which shows a 2-level menu of 7 options, each tied to 7 sub-options, as 49 basic types of help, some of which would connect to wp:Help_desk personnel who would likely answer most unusual questions within 10 minutes, as indicated by a time-for-response box (but we need to auto-correct the common edit-conflicts which delay Help_desk answers). Most help-menu options would likely lead to common FAQ pages, where perhaps the top 15 questions would answer the concerns for 85% of new users in that situation. Once people start thinking in terms of the "49 most-common help topics" and the "top 25 questions" (or confusions) for each of those 49 sections (1,225 common issues), then numerous problems tend to become very quick to resolve. The more the new users select among the 49 help options, then the more quickly they would remember how to get online help for specific types of issues. Do you see how that would work, and how new users would gain insight, over time, about 1,225 initially unfathomable issues? -Wikid77 (talk) 01:01, 4 June 2013 (UTC)

Constant logoff under Safari

Some time in the last couple of days, my machine will no longer remain logged in to the Wiki. It seems to correspond with the new login form (which is quite nice BTW) appearing. Navigating even a few pages eventually logs me out. Is anyone else on Safari having similar problems? (in fact, it lost my login WHILE typing this message) 108.168.95.104 (talk) 17:29, 2 June 2013 (UTC)

• Almost daily changes to MediaWiki configuration: For 2 weeks I have also experienced end-of-day automatic logoffs for the so-called "30 day" old login screen, but using Firefox, yet never clearing the stored cookies. I can detect when the MediaWiki interface is being fiddled, every day, because my browser cache goes haywire (often several times per day), which indicates some MediaWiki core files are in constant flux, unlike months ago. Here's the deal: if people find how to fix the 30-day login, today, that does not mean it will still work 10 minutes later (sorry, but reality). My favorite adage, "It's not whether you can fit 10,000 angels on the head of a pin, but whether you can keep them there". Always preview before posting a message, to check for auto-logoff as IP address. -Wikid77 14:08/23:57, 3 June 2013 (UTC)

Hey, I've tested this in Safari, and I'm not seeing any unusual behavior. Note that currently the login session is tied to your browser session, and if you don't check the "Keep me logged in" option, it will not remember you by default for 30 days. (For reference, the 30 day maximum is defined by our privacy policy. If you want to be able to stay logged in for longer as an option, I'd encourage you to keep an eye out for an upcoming discussion of a rewrite of the policy, and ask for what you want. There will be a length community consultation before it is finalized.) Steven Walling (WMF) • talk 18:50, 3 June 2013 (UTC)

I am wondering if a login+exit of browser (after +check "30 day") might help to remember the login username. Anyway thanks for running a sanity check of the Safari login, and explaining the dreaded 30-day limit. For users who run monthly update drives, the auto-logoff in mid-edit was a nightmare, causing the save to attribute an IP user to that revision, then exposing a person to wp:SOCKpuppetry claims when editing same page by both username & IP address at same time, leading to wp:Wikihounding at wp:ANI by witchhunt-like atmosphere, which means 3 days of reply-or-else, with potential to torture victim by ANI-dragout as inhuman 7-day torture of unredacted insult-per-minute, followed by 30-day block for wp:Wikilawyering for being "too right" in refuting false claims accurately, followed by lifelong grudges by admins who are afraid to be reviewed (etc.), all because 30-day login expired (oops, so FUBARed) before a 31-day month ended. Anyway never tie software operations to be policeman of policies, but allow each user optional restrictions, where the user is ultimately responsible for exceeding policies of 30-day max logins. -Wikid77 (talk) 23:57, 3 June 2013 (UTC)

@Wikid77: Did the above scenario that you speak of actually happen? Because it sounds like one of the most extreme cases of over-exaggeration I've ever heard, frankly. Theopolisme (talk) 00:10, 4 June 2013 (UTC)

There are posts of mine that are IP posts due to the fact that I've been logged out mid-edit... I use Firefox so I doubt it is Safari specific. Writ Keeper actually revdel one of them to protect my IP, the other times it has happened I said not to worry about it. Tracing my IP will just lead you to my university of which I've disclosed in a few places already anyways... Technical 13 (talk) 01:16, 4 June 2013 (UTC)

This is...

...the error I'm getting when trying to use "What links here ==> Redirects only". The article is Maria of Antioch. Thx. José Luiz ^talk 00:58, 3 June 2013 (UTC)

Yeah, it's broken everywhere. For some reason, that tool uses screen-scraping to get the list of redirects, a technique which is very prone to breakage. (That seems to be what's happened in this case.) The API would be a better alternative; however, this is up to Dispenser (talk · contribs) to deal with. — This, that and the other (talk) 01:11, 3 June 2013 (UTC)

So, you're actually saying that, up until this "Dispenser" does indeed decides to rethink the technique he used in this particular tool, a hyperlink active in every single enwiki article will be broken to everyone? IMHO, there should be some kind of governance about this s...tuff. Anyway, thank you. Let me see if I can sort those redirs out somehow. José Luiz ^talk 02:54, 3 June 2013 (UTC)

We can remove the link in the mean time. —TheDJ (talk • contribs) 06:35, 3 June 2013 (UTC)

Done. Using the "hide links" feature pretty much has the same effect anyway. Graham87 09:55, 3 June 2013 (UTC)

UTC Clock Gadget

I noticed something odd while editing with the UTC clock gadget. When I CSDed a page, the UTC clock read exactly 17:50:00, but the page history noted the edit as having occurred at 17:48. Any reason for this discrepancy? It's a minor issue, but it never occurred to me that the UTC Clock might be off. Altamel (talk) 18:10, 3 June 2013 (UTC)

It's probably just that there's a mismatch between your computer's time and the server's time. Wikipedia uses its own server time for the revision timestamps (naturally), but the UTC live clock gadget actually uses your computer's internal time, and the two can be out of alignment. You can see this by going into your computer's clock and advancing it a half hour: the UTC live clock will follow the leader and advance a half hour, while the revision timestamps will obviously not change accordingly. Writ Keeper ⚇♔ 18:18, 3 June 2013 (UTC)

• See mw:MediaWiki talk:Gadget-UTCLiveClock.js#Improvment of the clock gadget for more details and discussion on this. Technical 13 (talk) 18:26, 3 June 2013 (UTC)

Yep. My computer was about 90 seconds ahead of the U.S. Government's official time. Which is bad because supposedly, Windows is automatically synchronized with time.gov. Thanks for the help. Altamel (talk) 18:48, 3 June 2013 (UTC)

I had no clue that the gadget was dependent on my computer's clock. Thanks for the details! Nyttend (talk) 03:50, 4 June 2013 (UTC)

Archives

I recently set up one of the MiszaBots to archive my talk page, and it came with a fancy box to display links to old archives. I have two archives set up so far by the bot, but no links to them on my talk page. What's going on and can it be fixed? Thanks, TheOneSean ^{[ U | T | C ]} 18:14, 3 June 2013 (UTC)

I've made an edit, and the names are now showing. Unfortunately the {{archives}} template can only display the names automatically if you are using the simplest naming scheme. -- John of Reading (talk) 05:27, 4 June 2013 (UTC)

Other languages

 Done

Hi, the en:WP page Magallanes & the Chilean Antarctica must be linked to the es:WP es:Región de Magallanes y de la Antártica Chilena. I added the link on the old way but I guess that it will be deleted. Can anzone of the admins add the link in the new fashion way?. Thanks a lot. --Best regards, Keysanger (what?) 18:50, 3 June 2013 (UTC)

The proper way to manage language links now is by editing Wikidata. You don't need to be an admin to change language links. In particular, this entry is wikidata:Q2189. As it turned out, the English language link was pointing to a redirect (Magallanes y la Antártica Chilena Region) instead of the main article (Magallanes & the Chilean Antarctica), which was preventing the language links from showing properly. I fixed it and now all seems kosher. Jason Quinn (talk) 19:06, 3 June 2013 (UTC)

Thanks again. --Best regards, Keysanger (what?) 19:24, 3 June 2013 (UTC)

Tech news: 2013-23

Latest tech news from the Wikimedia technical community. Please inform other users about these changes.

Recent software changes

(Not all changes will affect you.)

• The latest version of MediaWiki (1.22/wmf5) was added to non-Wikipedia wikis on May 29. It will be enabled on the English Wikipedia on June 3, and on all other Wikipedias on June 5. [44]
• The Tamil Wikipedia shared a Lua module they created to automate their Main Page. [45]
• There is now a test wiki to test new features in right-to-left languages. [46]
• The Thanks feature was added to the English Wikipedia; users can now thank others for individual edits. [47]
• The new interface for account creation and log-in is now the default on 30 wikis, including the English Wikipedia, Commons, Meta, and Wikidata. The feature will be added to all wikis after June 5. Users can return to the old look by adding ?useNew=0 to the web address. [48]
• Videos are now played in pop-up windows if their size on the page is smaller than 200 pixels (800 pixels on the English Wikipedia). [49]
• Opening your talk page now marks notifications as read, for wikis using the Notifications feature. (bug 47912) [50].
• All autoconfirmed users can now reset transcoding of video files; previously only administrators could do this. [51]
• The Nearby feature allows people who use mobile devices to see Wikipedia articles about objects and places around them. [52]

Future software changes

• The PostEdit feature is now part of MediaWiki, and will work on all wikis. (bug 48726) [53]
• The Narayam and WebFonts extensions will be replaced by the Universal Language Selector extension. [54]
• MediaWiki will now be updated every week, starting on June 6. Thanks to this, bugs will be fixed and features will be added faster than they are now. [55]

Tech news prepared by tech ambassadors and posted by Global message delivery • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

19:15, 3 June 2013 (UTC)

Trademark discussion

Hi, apologies for posting this in English, but I wanted to alert your community to a discussion on Meta about potential changes to the Wikimedia Trademark Policy. Please translate this statement if you can. We hope that you will all participate in the discussion; we also welcome translations of the legal team’s statement into as many languages as possible and encourage you to voice your thoughts there. Please see the Trademark practices discussion (on Meta-Wiki) for more information. Thank you! --Mdennis (WMF) (talk) 01:26, 4 June 2013 (UTC)

It's okay, we forgive your English! :) Theopolisme (talk) 02:02, 4 June 2013 (UTC)

Thanks extension

Hey all. As described on this dedicated page, we've built a system to thank editors for individual edits. As I'm sure you're all aware, it's relatively trivial to deal with bad contributions (undo and rollback are your friend!) but we don't really have any way in MediaWiki to encourage editors who have made good edits. We can send out barnstars, sure, but barnstars are justifiably Kind Of A Big Deal - they're for really substantial contributions or a large number of small ones. There's nothing to thank people for individually helpful, gnome-ish edits except dropping a personal note - which is quite a lot of effort to do every time someone corrects a typo.

The Thanks extension solves for this; with it, you can send an editor a notification about the value of their edit with a couple of button-clicks. If you're not a fan, there will be preference options to turn off (respectively) receiving thanks, and seeing the interface elements of the extension at all. You can read more here :). Okeyes (WMF) (talk) 19:53, 28 May 2013 (UTC)

• We really need other things: Look, these Send-thanks buttons are interesting, but we really need several other things first:

• Fix edit-conflicts of 2 replies: We need an edit session to auto-merge two replies, or 2 lines added after the same line.
• Allow '#' inside a title: We need to create titles like "C# or Bb" (See sharp or Be flat), the old joke sign on the front of a piano-mover truck, so the page does not insist the title is simply "C" with appendage "# or...".
• Raise expansion-depth limit: We have several templates that are just a few levels too deep, and raising the wp:Expansion depth limit, from 40/41 to 50/51, would fix thousands of articles, especially numerous animal species, to reformat better.
• Set a parameter value {{set:x|45}}: Many templates run 10x-20x times too slow because they keep re-calculating the values, over and over. Instead, if we could reset or store the calculated parameter values within subtemplates, as {{set:long_calculation|467000.32}}, then many templates could run 10x-20x times faster, with lower expansion depth.

Fixes to those few simple problems, listed above, could help many thousands of users. I understand you want us to thank people, but really, those other problems from 7 years ago, are much more important at this point. Meanwhile, as you are auto-merging 2 replies in edit-conflicts or fixing titles to allow '#' or storing {{set:x|45}}, then we will struggle, for the next several months, to somehow send users the 5 words, "Thank you for your edit". We really need the important things done first, but thank you, in advance, for fixing the important issues first. -Wikid77 (talk) 08:14, 30 May 2013 (UTC)

For the "parameter value" one, the best way forward there is Lua. That may also help with some expansion-depth cases. There is actually a redirect at both C♯ (C sharp) and B♭ (B flat). You probably mean "#", though, which is very tricky since that inherently has a special meaning both on Wikipedia and the web (bascially a section). There is nothing special about ♭ though. I'm not sure exactly what scenario you mean for the 2 replies, but you should make sure it's in Bugzilla. There are teams (namely Wikimedia Platform Engineering) specifically working on issues like this. They're the ones that helped develop the Lua extension, among other things. So understand that different teams are going to focus on different problems. Superm401 - Talk 05:07, 31 May 2013 (UTC)

I just went to undo some changes by a POV pusher, but accidently thanked them as this was where I expected the 'undo' option to be - not good design IMO. I've just turned this option off. Nick-D (talk) 02:31, 1 June 2013 (UTC)

Me too. Wikipedia:Notifications/Thanks#How to turn off this feature for others. Tassedethe (talk) 00:47, 3 June 2013 (UTC)

I came looking for discussion of this thing as well, had no idea what this dumb thing was til I "thanked" a bad edit, meaning to revert. Tarc (talk) 12:25, 4 June 2013 (UTC)

Nice to see work, but please go easy

Hi. By all means don't take me too seriously, I am likely *not* your target audience (not a young enthusiast, rather a disheartened old-timer) , but well... I have been mostly out for about a month or so. I get back to a lot of changes, and it is good to see folks are trying to improve WP. The problem is that is getting, for my reading preference, a unreadable mess. There are notifications in coloured boxes that pop up. The notifications themselves look excellent - it is the implementation that looks crappy: the colours and pop-up windows are very not WP-like (maybe that is the start of new WP look?). Not to mention being released apparently without the very minimum of testing (I got a talk message by 1 (one) user and notification about "<username> and 1 other posted on your talk page", while there is no 'other', how can a serious test miss that?) Anyway, get on with it, it looks promising. And the links are weird, with a dotted underline (?) and pop-up hints? Also it looks like I am back 20 years, sometimes pages take 10+ seconds plus to load and they are so full with, I can't be sure, javascript?, that the page keeps on moving around, building up, all the time. It is the back to the 1990s and waiting for those (then) huge pictures to load? To those working hard to improve: thank you for your work, there are some valuable contributions. But please, do not over do it. A Encyclopaedia one can't load nor read comfortably, is useless. - Nabla (talk) 02:24, 29 May 2013 (UTC)

Nabla, the new notifications aren't for everyone. And Wikipedia has no "target audience." And if you're feeling disheartened, I'd be glad to help you with that. Just drop me a talk message. But, notifications, you can turn them off and go back to the Orange Bar of Doom if you wish. Go to "Gadgets" under Preferences, and select "Display a floating alert when I have new talk page messages." That should do it. And on page weight, that might be a problem with your browser or computer, or maybe a WP bug. The dotted underline etc. I'm not sure about, but I'm sure someone else will know. But drop me a line on my talk page, we'll have a chat. Thanks, TheOneSean ^{[ U | T | C ]} 11:55, 29 May 2013 (UTC)

• 10-second delays to format sidebar menus and Insert-menu: I think the 10-second delays, which cause the screen to shift around every few seconds, are related to the auto-collapsed sidebar menus, such as >Interaction or >Toolbox. Perhaps someone knows a way to turn off those collapsed menus, and just show the rapid simple menus from last week, last year. I think many people are learning there is a thin line between "user-interface design" and "user-interfere design". In general, do not move the steering wheel or brake pedal every other day; instead keep navigational controls stable, to avoid even worse user frustration.
• Petition to reduce user-interface changes: Many other users have noted severe problems with using the new Wikipedia screens, such as the orange-bar segment for new-messages will lock out some menu options. See petition:

• "WP:Petition to the WMF on handling of interface changes"

Numerous comments have been added to the petition, about various issues, and slowdown or browser lockup problems. This isn't Facebook where people come to see their "likes" accumulate in a like-counter. However, the developers are smart enough to stop this, and fix real problems. They recently fixed support for IE8 browsers (world's most popular) to align screen boxes, even to position the map-locator dots to the exact pixel, while adding Wikidata support. -Wikid77 (talk) 08:50, 30 May 2013 (UTC)

@Nabla: "the colours and pop-up windows are very not WP-like". Just out of curiosity, are you a monobook user ? Why do you think it is not 'Wikipedia-like' Because we never really had a colorscheme that we truly identified with I think. —TheDJ (talk • contribs) 21:51, 31 May 2013 (UTC)

@TheDJ: I am using Vector, fully standard except for four CSS line highligting Portuguese and other non-English text. The non-WP looks come from increasing the number of colours: we had black/blue/red text on white/blueish light grey background, now there is white text on a dark gray box prominently on top, plus the silly green "edit saved"... floating window, also a floating window for the notifications. How come pop-up windows suddenly became a good thing (javascript pop-up is good, html pop-up is bad? why?). - Nabla (talk) 00:00, 2 June 2013 (UTC)

@Nabla: I agree with you that the theme of post edit is somewhat out of place with the rest of site. The 'white on gray' I find a tad less convincing, it's just inversion in order to make it stand out a bit more. The idea of ajax for post edit is clear, you only want to show it very temporarily, and you don't want to affect the flow of the content any more than required. Personally though, I think it's positioning can be improved and so can it's color scheme. For notifications we have a similar problem. The idea is to give the user many more notifications, configurable and live (so not just when navigating pages). Doing that with plain html is almost impossible to do, while not also aggressively taking away realestate from the content.
Also, there is no such thing as html popups. There is html content, ajaxified html content (which can be overlayed on top of other content) and alert dialogs. With the increase in interaction, you will see more ajax based content, simply because it saves you a ton of pageloads. It's only logical. Users who don't want to use ajax, will have to make those many page navigations, but it doesn't make sense for the majority of users if you ask me. Anyway, in terms of design, you will see more Echo, then postedit from what I have seen of projects being discussed. Postedit is the odd man out. —TheDJ (talk • contribs) 17:31, 2 June 2013 (UTC)

@TheDJ: The problem with the "post edit" is it existence, whatever way you do it it is silly. Having a floating window that does not fit in, actually is a must, otherwise it would be doubly silly: to have a warning that noone can see :-) «The 'white on gray' [...] it's just inversion in order to make it stand out a bit more» Evidently, and it does stand out, and THAT is the problem :-) Why do we want a "0" (i.e., no news) to stand out?

As to «Doing [many notifications] with plain html is almost impossible to do, while not also aggressively taking away realestate from the content.» Why do we need 'many' notifications? And assuming we do, why do they need to be mingled with / on top of the content? Tabbed browsing is perfectly standard nowadays, so we could have a dedicated page, with all the space in the world for notifications (and we already do right?) plus a small warning on the 'main' page (if we really must - which we already do have also). Any editor interested in the notifications would look into the notifications page once in a while, or after getting a warning. The concept of having multiple place-holders (i.e. windows) to differentiate content isn't exactly new :-) I currently have 24 tabs/windows open across 6 workspaces - I bet you do not advise me to try and cram them all in a single window :-) So why exactly do we *need* to a have a loong list of notification on top of content?.

«there is no such thing as html popups» ? I am missing something there. Yes, there are no html pop ups in WP, but there are html pop-ups, right? <a ... target='_top' ...> or something? And they were usually frowned upon. Why is javascript pop-ups a good thing, and html pop-ups a bad thing?

Mostly rhetorical questions, I am fine that we disagree with no need of further explanations. - Nabla (talk) 23:43, 3 June 2013 (UTC)

PS: You almost completely lost me with the last paragraph... I have some faint idea of what is "ajaxified content", but I "will see more Echo"?? "Postedit is the odd man"?! - Nabla (talk) 08:35, 4 June 2013 (UTC)

Annoying Dev changes

OK devs keep screwing with the UI in monobook without really adding anything. They added #mw-watchlist-resetbutton to the watchlist which does nothing, So I hid it via AdBlock plus, This was recently modified to use a FORM#mw-watchlist-resetbutton which cannot be hidden. PLEASE stop screwing with the UI so that annoying useless "Features" can be killed once and forgotten about. Werieth (talk) 15:04, 31 May 2013 (UTC)

I agree. It seems too much time is being spent adding useless widgets, gadgets, wingdings and nonesense that doesn't "fix" anything. There are a nearly countless number of problems that could/need to be addressed but we keep wasting time on stuff no one is complaining or cares about. Half the crap doesn't even work or doesn't work right. Even worse most isn't wanted by the community and seems to be tailored n the assumption that if we make WP look more like Facebook more editors will be attracted to editing. Kumioko (talk) 15:10, 31 May 2013 (UTC)

"If we make WP look more like Facebook more editors will be attracted to editing"...yeah; that's at least part of it. See countless threads above. Theopolisme (talk) 15:16, 31 May 2013 (UTC)

Yes and its a massively incorrect assumption. I could explain in great detail why by giving some Sociological and technical reasons but its akin to making a car as big as a truck to attract truck buyers. Even f you attract the truck buyers you lose support from the car crowd. It seems like the Scifi channel just did something like this recently, Facebook did it with the hated timeline. We have to remember that the purposes for Facebook and Wikipedia are completely different as are the cast of characters that use and support them. Some features may be appropriate to use between the 2 but many are not. We shouldn't copy them just in the hopes that it "might" attract some new users. Kumioko (talk) 16:52, 31 May 2013 (UTC)

this has absolutely nothing to do with facebook. the added functionality allowing to distinguish between "read" and "unread" entries in the wathclist is very useful, and vast majority of users just love it. every forum software let me see in a glance which threads have new posts since i last visited them, my email client distinguish between read and unread emails, and it's a very good thing that WP allows this too. for the few and rare people who wish not to use this feature, enwiki added a special gadget that allows one to hide it. this feature comes with a button to "mark all pages visited". if it bothers someone so much, it can be easily hidden by editing Special:MyPage/common.css (just add the line

#mw-watchlist-resetbutton { visibility: hidden; }

peace - קיפודנחש (aka kipod) (talk) 17:24, 31 May 2013 (UTC)

So how did your description have anything to do with the new login page, the replacement of the OBOD with the number or the other things that bare a striking resemblence to Facebook? I agree that it can be beneficial to see if the aricle has updated since the last time I visited, but many of the other changes are less useful. In the end though it doesn't really matter. They aren't going to remove it once they have implemented it and I am certain there are more insignificant changes coming in the future. My only hope is that in the quest to make all these changes to Facebookize Wikipedia to recruit new people we don't drive away more that are currently here contributing. Kumioko (talk) 17:59, 31 May 2013 (UTC)

In 2 months, the May/June editor-activity data will reveal how many people gave up trying. Most people (74%) do not post to talk-pages, and they might continue editing as totally oblivious to other concerns. -Wikid77 19:42, 31 May 2013 (UTC)

my description has nothing to do with all these things. this section is not about them - you might want to go to the top and read what this section is about.

if you wish to hijack this discussion and whine about the login screen and other such things, there is little i can do to stop you, but it seems to me a bit pointless: there are several other sections on this very page that do deal with the login page and the rest of the stuff, so it's not like you have nowhere to whine about the things you want to whine about. peace - קיפודנחש (aka kipod) (talk) 18:23, 31 May 2013 (UTC)

Your attitude is typical of the problems that plague this site. A user voices conerns about poorly implemented and poorly thought out system changes and there written off as whining. Kumioko (talk) 18:28, 31 May 2013 (UTC)

• Contact WMF product managers such as User:Fabrice_Florin_(WMF): We need to contact people who can change direction, rather than have the "tail wag the dog" and if we can get a discussion scheduled with User:Fabrice_Florin_(WMF), product manager of editor engagement tools (wp:Notifications & Thanks-buttons), then perhaps we can reduce the interface shock, while resetting priority on major issues instead. For example, I would think quickly fixing the 2-reply edit-conflicts could be part of the discussion, such as have an "edit-merge screen" to retro-insert changes into the recent revision for edit-preview, for complex edit-conflicts. Any bugfixes beyond those products might get referred to the specific WMF manager in charge. -Wikid77 (talk) 19:42, 31 May 2013 (UTC)
  • Edit conflicts in discussions will be solved by Flow so you don't need to worry about that much. --Jorm (WMF) (talk) 20:01, 31 May 2013 (UTC)
  • That might help but I'm not going to worry about it. I haven't gotten the impression that they generally care about what we as a community think. And why would they, we can't do anything even close to implementing changes. I have voiced my opinions and will continue to do so. I know that they watch these discussion boards and maybe they'll start adjusting their direction if enough people comment. I doubt it though. Kumioko (talk) 19:48, 31 May 2013 (UTC)
    • You say "we as a community" like en.wikipedia is the only community they have to listen to and take opinions and ideas into consideration... Wikipedia might be bigger than you think... Technical 13 (talk) 19:56, 31 May 2013 (UTC)
      • I'm active on English and German Wikipedia as well as on Commons (the three largest projects I assume) and tenor seems to be the same on all of the three projects. So if WMF cares about another part of the community with their actions, they should start to explain themselves better. --Patrick87 (talk) 20:33, 31 May 2013 (UTC)
        • And even if other projects wanted the changes or didn't care, they could care about us by not installing certain components here that they've installed elsewhere. Technically speaking, there's no reason to require that all Wikipedias use the same software. Nyttend (talk) 12:20, 4 June 2013 (UTC)

"Missing operand" problem

For quite some time, my monobook.js page hasn't been loading. At present, the editing tools won't load, and Pilaf's Live Preview Lupin's pop-ups won't display either. Even refreshing it (or opening Internet Explorer 10) won't help solve it.

I'm not sure what's happened, but when I go to "Inspect element" from any WP page using Chrome 27 (Windows 7), I get a message which says:

 Uncaught Error: JavaScript parse error: Parse error: Missing operand in file 'User:Slgrandson/monobook.js' on line 54

I managed to trace that 54th line by hand, and it appears to come before Raylu's deletion-sorting tool. I still can't be so sure; which parts aren't working within this code? --Slgrandson (How's my egg-throwing coleslaw?) 23:16, 31 May 2013 (UTC)

Remove the HTML comment on line 54 – that's probably all. --Patrick87 (talk) 23:25, 31 May 2013 (UTC)

The syntax <!-- comment text --> is not valid javascript. Both of these lines should be either removed, or altered to the /* comment text */ form. I also notice four instances of document.write( ... ); which I believe are now forbidden by MediaWiki. --Redrose64 (talk) 23:34, 31 May 2013 (UTC)

Readjusted with those tips in mind--and what do you know! I've got them back. Thanks! --Slgrandson (How's my egg-throwing coleslaw?) 01:10, 1 June 2013 (UTC)

Wait, my what? -raylu^T 21:29, 4 June 2013 (UTC)

Forcing HTML 5

In the announced plans to force use of HTML 5, I am wondering how will the outdated HTML tags be handled, such as <small> or <center> or <font face=Georgia>, and table attributes: border=1 or cellspacing=2 or cellpadding=3 or valign=top. Up to now, the MediaWiki parser has been using pseudo-HTML as "text formatting directives" as if it were part of the macro scripting language, where marking a column for vertical alignment (valign=top) would convert the pseudo-HTML into: valign="top". But now, after the massive fiasco of dropping the orange new-messages bar, to confuse 50,000 active registered editors, I am "slightly concerned" that the next MediaWiki shock will be bizarre rejection of "valign=top" rather than merely continue support by translating pseudo-HTML into the longer HTML-5 equivalents. Any word on how disasterous the forcing of HTML 5 will be in the next MediaWiki upgrade/downgrade, as perhaps handled by a different WMF department than the new-messages bar? -Wikid77 (talk) 11:17, 3 June 2013 (UTC)

Er. What announced plans? Okeyes (WMF) (talk) 12:33, 3 June 2013 (UTC)

Ditto. And <small> is not obsolete in HTML5.[56] --  Gadget850 ^talk 13:07, 3 June 2013 (UTC)

But it did undergo a semantics change ("was for smaller text, now used for side comments and small print").[57] Jason Quinn (talk) 18:52, 3 June 2013 (UTC)

• Fortunately, using "<small>" is still safe, but as stated in the archive page (/Archive_112#Tech_news:_2013-22): "MediaWiki will stop supporting XHTML 1.0 and HTML versions lower than version 5. HTML5 will now be the default language for pages created by the software." And so, I am wondering what will happen to "valign=top" in table columns. -Wikid77 (talk) 14:46, 3 June 2013 (UTC)
  • All Wikimedia sites have been using HTML5 output for many months, when the configuration was finally changed to $wgHtml5 = true. The upcoming change simply removes the legacy code supporting $wgHtml5 = false from the MediaWiki software. As far as I can make out it should have no effect on Wikimedia sites. the wub "?!" 16:21, 3 June 2013 (UTC)
    • And why can I still use non-conforming features like teletype text, striked text, big text and the like? Shouldn't tey be prevented if we already produced standard conforming HTML5? --Patrick87 (talk) 17:27, 3 June 2013 (UTC)
      • Mediawiki does run its output through HTML tidy, but they do not clean up such things. Browsers have no problems handling them, as you can see. But if you look at the source of this page, it says <!DOCTYPE html> ,which means HTML5. The main issue in changing to HTML5 is that Mediawiki no longer guarantees the source is well-formed XML. The usual formatting commands still work fine, e.g. <font>. — Carl (CBM · talk) 17:28, 3 June 2013 (UTC)
        • HTML elements and attributes are whitelisted by Sanitizer.php. Help:HTML in wikitext#Obsolete elements notes the obsolete elements. Even though obsolete, browsers will probably support them forever. --  Gadget850 ^talk 17:45, 3 June 2013 (UTC)
          • And there is a bug report requesting that obsolete elements be converted. Have to did around to see the status on that one. --  Gadget850 ^talk 17:47, 3 June 2013 (UTC)
            • So we're producing nonconforming code on purpose? I hope I don't have to understand this. The correct way would be to either deprecate those HTML tags completely and offer something similar through Wikitext or substitute them automatically (e.g. replace <big> with <span style="font-size:larger;"> --Patrick87 (talk) 17:54, 3 June 2013 (UTC)
              • T41614 Replace deprecated HTML tags in HTML5. Each of the obsolete tags has a matching template, except for <tt>, which has other replacements. And if you want to just turn off <font>, then please have a plan in place to update signatures. In the scheme of things, this is a minor issue. Rather irritating when validating a page. --  Gadget850 ^talk 19:41, 3 June 2013 (UTC)
                • On the other hand, see T42632 where code doing this sort of thing was removed after it proved more trouble than it was worth. Anomie⚔ 02:02, 4 June 2013 (UTC)
                  • Exactly. The latest ideas on this are that some 'transformations' will be added to parsoid to actually move away from all deprecated HTML elements. But this is not definitive. For now, we will potentially output non-compliant HTML5 for some of the user generated content. There is nothing wrong with this, compliancy with specific versions of HTML has sort of become obsolete with the concept of a living HTML standard as professed by HTML5 and the browser vendors. All browsers will recognize these elements into infinity most likely, and if they don't we can do some things at the server side, before users are bothered with it. So no panic needed, users won't notice a thing about this change. —TheDJ (talk • contribs) 11:36, 4 June 2013 (UTC)

Check For Identical Edits

I started a conversation here: http://en.wiki.x.io/wiki/Help_talk:Edit_conflict#Check_for_identical_edits.3F . I am moving it here. — Preceding unsigned comment added by TheUnknownNinjaNN2 (talk • contribs) 05:26, 4 June 2013 (UTC)

• Also rare bug says edit-conflict when none: Although it might seem an edit-conflict was caused by hitting "Save page" twice, there have been cases where a single Save would trigger an edit-conflict preview, but "Show changes" would confirm no other edits to that section, and in fact no other edits to the entire page, but still refuse to save the changes. We are not sure if the false edit-conflicts are perhaps caused by logic errors in the page-submit, such as thinking an extra paragraph which was added at the end of a page is perhaps sometimes an edit-conflict. -Wikid77 (talk) 11:34, 4 June 2013 (UTC)

  I've seen this phenomena myself and usually can find where it thinks that a blank line was added or removed somewhere else. I usually look over to see what the conflict is, and if there is no other person's comment, I scroll to the bottom, click on the "Your text' box, hit ctrl+a then ctrl+c scroll back up to the active edit box and press ctrl+a then ctrl+v then Save. I'll try a little harder to take exact notes about the placement and +/- of the blank line conflict. Technical 13 (talk) 12:14, 4 June 2013 (UTC)

I have occasionally bumped it twice though. It is not responding so I click again. Sometimes, I missed it on this tiny screen. Sometimes, it was slow internet.

TheUnknownNinjaNN2(Talk,Always willing to discuss this subject) 23:25, 4 June 2013 (UTC)

Problems with watchlist green bullet

A week or two ago, a new line appeared near the top of my watchlist noting that "Pages that have been changed since you last visited them are shown with a green bullet." I have yet to see any green bullets so I assumed that this was yet another buggy feature forced on us without adequate announcements or testing. That's disappointing but I found the gadget in my user preferences that purports to turn this feature off entirely. However, the line still appears at the top of my watchlist. Is this a bug in the gadget that can be fixed? Or is there some other way to remove this broken feature from my watchlist? ElKevbo (talk) 06:16, 4 June 2013 (UTC)

I would hope that the gadget can be fixed, but until then you can add this line to User:ElKevbo/common.css -

#mw-wlheader-showupdated { display: none; }

-- John of Reading (talk) 06:22, 4 June 2013 (UTC)

I fixed the gadget. —TheDJ (talk • contribs) 10:19, 4 June 2013 (UTC)

Can you fix it to disable the bolding too? Werieth (talk) 10:28, 4 June 2013 (UTC)

Awesome. Thanks so much to both of you! ElKevbo (talk) 16:00, 4 June 2013 (UTC)

• Yeah, I didn't see them at first either. They firstly do not show up if you are using enhancedRC. Secondly, if you are not using enhancedRC, the difference in the colors is near indistinguishable with certain color blindnesses or even if you have a dull screen (I had to use a tool called Instant EyeDropper that tells you the hex code of colors on the page). So, if any of those situations apply to you (I use enhancedRC myself) then the css John of Reading suggests is the way to go to make that annoying inaccurate statement go away. Happy editing! Technical 13 (talk) 12:05, 4 June 2013 (UTC)

Preferences-Browsing-Navigation popups

I just disabled my popups. I think someone is diddling with them, as of within the last hour, and it wasn't working for me. Instead of the popup happening where my pointer was, the popup started appearing as a narrow vertical sidebar on the far right of the screen. It was less intrusive. However, what the change did was make it impossible to go on the popup to disable it. I could get to "popup", but when I moved the pointer to click on "disable", it totally flipped and ran lengthwise and I never figured out where "disable" went to. Somewhat annoying. — Maile (talk) 15:52, 4 June 2013 (UTC)

The gadget hasn't been changed since 11 january. —TheDJ (talk • contribs) 16:06, 4 June 2013 (UTC)

Interesting. Well, whatever caused it, I think I can live without the gadget. Thanks for your quick reply. — Maile (talk) 16:25, 4 June 2013 (UTC)

Edit counter problem

When I go to X!'s Edit Counter for myself here, it shows that I have no deleted edits, which I most certainly do. (Not that I'm bragging about having deleted edits.) I use IE10 to edit, but I also have Google Chrome. When I put the URL into Google Chrome, the exact same thing happened. öBrambleberry of RiverClan 15:55, 4 June 2013 (UTC)

See #Toolserver issues above. GiantSnowman 16:01, 4 June 2013 (UTC)

Need help at Template:Commons and category-inline

I've noticed that Template:Commons and category-inline does not allow two parameters to list the Commons Page and Category, when they are not the same, such as Commons:Automobile and Commons:Category:Automobiles. The companion template, Template:Commons and category, does allow the two parameters. Since I have yet to figure out how to modify the template to make it work, would someone who is really good with templates be able to add this functionality to this template? Thanks much in advance! --Funandtrvl (talk) 18:21, 4 June 2013 (UTC)

I've made the change. It should now work as expected. — Edokter (talk) — 18:44, 4 June 2013 (UTC)

Wonderful!! --Funandtrvl (talk) 19:28, 4 June 2013 (UTC)

One problem, I updated the /doc page, because the 2nd parameter (Commons category) does need to be specified, if it is not the same as the default, which is the PAGENAME. Both templates seem to work this way, maybe the default for the second parameter should be the 1st parameter, if nothing else is specified, instead of PAGENAME. --Funandtrvl (talk) 19:57, 4 June 2013 (UTC)

I thought the first sentence summed that up pretty well. — Edokter (talk) — 20:36, 4 June 2013 (UTC)

Lua and date/time templates

We have a number of date and time templates, including {{Start date}}, {{End date}}, {{Birth date}}, and many more in the latter series. These could do with being re-written in Lua, which will make them faster, and allow us to both increase their usefulness and to detect and warn about errors (similar to the recent re-write of our referencing templates).

It makes sense to do this in a coordinated manner, rather than individually, and to see whether we can give them a common core.

I'm not a Lua coder (I'm interested in learning, but that's a separate issue), but I do understand the various templates' inputs and outputs, and have worked to develop them for several years,

There is also discussion of similar date coding for the |published= parameters in reference templates.

Would anyone be interested in taking on this project? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:25, 29 May 2013 (UTC)

I'd be willing to co-op with someone - I don't have enough time to do it all by my lonesome. Anyone? TheOneSean ^{[ U | T | C ]} 15:38, 29 May 2013 (UTC)

• Date templates run 85/second and omit invalid months: I do not see the need to rewrite Template:Start_date (in 113,000 pages) or Template:End_date to use Lua script, because they already run faster than 85 per second (typically used once per article), and if the month number is invalid, then no month name is displayed, clearly indicating the month code was not correct. Meanwhile, as we have found with the Lua-based wp:CS1 cite templates, people either check the results or they don't, and showing Very long red error messages has not stopped people from adding more invalid data into Wikipedia articles, whether minor or major pages. Plus showing the glaring red error messages does not force readers to edit and fix the pages, within a few days or weeks, while it only makes articles look trashy for the vast majority of readers, all for what, to say, "April 31 is invalid" where "April 30" should be the value, or who knows what to put there? ...and how does that really help the readers of 81,000 film articles or others? There is no reason to highlight an error in a date which the reader might not even notice, and even if they do, then the readers will realize "April 31" is invalid, without a red-error message to inform their South Park "warped little minds" as if the readers were clueless about dates. Another issue we learned from using Lua, in the earlier Lua cites, was how every small tweak to alter or restate the red-error messages (which most readers have ignored) had merely triggered the daily reformatting of 2 million pages (for weeks), which made the Toolserver wp:REPLAG delay fall days further behind. Plus, what if the Lua rewrite introduces subtle new date-formatting bugs which do not exist now because of current unknown parameter interactions, and all for what? Sorry, I have done the tedious analysis, and I do not see the need to "re-invent the wheel" of date formatting. This is another YAGNI distraction from high-priority issues. However, thanks for asking, because it sets a clear example for where Lua script is not needed but risks new bugs, plus red-error scarring of some pages, with massive re-reformatting of 110 thousand related articles, for every update of the Lua versions. -Wikid77 (talk) 10:42, 30 May 2013 (UTC)

Funny, I don't recall asking for "red-error scarring"; your "new bugs" hypothesis is FUD; and your screed ignores the additional functionality which i did propose (and which has been suggested for some time on the talk pages of some of the templates involved). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:49, 30 May 2013 (UTC)

It is a rule-of-thumb, in computer work, how 10% of bugfixes cause more bugs, and rewrites are even worse. As for enhancements, the markup-based templates run 85/second (used mostly once per page) and could handle new options checked at the rate of 750/second or faster. -Wikid77 15:45, 30 May 2013 (UTC)

I have an question. Why does not a single one of those three templates (start date, end date and birth date) use the time parser function ?--Snaevar (talk) 11:47, 30 May 2013 (UTC)

I think those templates were just too rapid, and simple when showing "Month d, YYYY" format, to need #time, while running 85/second, and I could optimize them to run over 100/second, but I will try your suggestion in benchmarking. Thanks. -Wikid77 15:45, 30 May 2013 (UTC)

• Using #time is 2.1x faster as 182/second and checks date errors: I have run more than 15 benchmarking tests, to show how using function #time to show the "Month" name will quicken Template:Start_date/sandbox to run 2.1x times faster, as 182 dates/second. However, #time will issue the red-error scarring "Error: Invalid time." for invalid month/day, which might not meld with prior usage of the template in 113,000 pages (infoboxes), where invalid dates were ignored, showing whatever day "34" or such. -Wikid77 16:26, 30 May 2013 (UTC)

Converting to Lua would also allow for far better error checking, as recently suggested at Template talk:Death date and age#Math bug. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:20, 4 June 2013 (UTC)

"Date templates run 85/second and omit invalid months" -- NO, THEY DON'T (omit invalid months); at least this one doesn't, as per the link above Template talk:Death date and age#Math bug Lx 121 (talk) 20:13, 5 June 2013 (UTC)

Anonymity of WP:Third opinion requests

WP:Third opinion says to include

• A five tilde signature (20:34, 30 May 2013 (UTC)) to add the date without your name.

and it includes this note - which I added a while back:

• (Note: your name will still be shown in your contributions and edit history.)

Users should be able to request third opinions anonymously. Why can't they? How can editors be empowered to do so?

• Note: proposal edited to reflect refinement and offer from Theo.
  

Blocked users can edit only their own talk pages, so it would presumably be easy to make an account that anyone could use that could only edit WP:Third opinion. Any thoughts on how easy that would be?

Or, we could make it so that users' edits to WP:Third opinion were not logged (in the normal way; we could have logs that oversighters could see and we'd want 3O providers to still be able to know when a 3O had been requested.) Any thoughts on how easy that would be?

We could provide a bot that copied requests received via a web form. Any thoughts on how to do it or how easy that would be?

We can and should provide actual 3O requester anonymity as long as we're telling 3O requesters to sign 3Os with ~~~~~ to be anonymous.

Pitfalls? Is this mature enough an idea to file a bug report? --Elvey (talk) 20:34, 30 May 2013 (UTC)

If there's interest, it could be done through a web portal and a bot, which I'd happy to configure. However, I'm curious--why does this have to be anonymous? If the dispute is between two people, won't the disputants both know who requested it? And even if the third party doesn't know who requested it, does that really matter? If they have a conflict of interest with either of the parties, they probably shouldn't be assisting, period. Theopolisme (talk) 20:41, 30 May 2013 (UTC)

I'm not familiar with 3O, but a quick search of the 3O talk page archives turned up these two discussions: Wikipedia_talk:Third_opinion/Archive_5#Not_listing_requesting_editor.27s_name and Wikipedia_talk:Third_opinion/Archive_4#Why_no_signatures.3F. Those might shed some light on the subject. jcgoble3 (talk) 23:13, 30 May 2013 (UTC)

Thanks, Jonathan! @Elvey: I can create a web form (+bot to add them to WP:3O) for submissions if that's what y'all would like. Theopolisme (talk) 01:44, 31 May 2013 (UTC)

• I'm entirely opposed to such anonymity, but am heading to bed and can't type long explanations well on this cell. I'd be happy to do so in the morning though. Technical 13 (talk) 02:18, 31 May 2013 (UTC)

  Okay, good morning! The reason I am opposed to such anonymity is the fact that as a respectable person that respects the process, I do not want to offer a third opinion on a dispute where I'm familiar with either person currently involved. It is a waste of my time to have to go to the location of the dispute to see who is involved before I decide if I want to say anything or remain silent. The normal process for such response is to read the dispute, research both claims to try and see it from both perspectives, and respond one way, the other, or with a compromise that may be satisfactory to both and always in a neutral tone. In the process of leaving a response, it is normal practice to add a reasonable edit summary and check the "Watch this page" checkbox to add it to my watchlist so I can monitor for responses and questions. So, if there was anonymity amongst both of the other parties (they would have to remove all of their signatures from the talk page as no-one goes into a discussion expecting to need to 3O), and request assistance without a signature, then the responder would be going in not knowing who was involved so they could avoid situations where they know one of the people opening them up to claims of favoritism and sneaky emailing and working behind the scenes in a canvassing way to sway a dispute one way or the other. I personally wouldn't want to get caught in that kind of mess and would likely quit offering 3Os if I had to work extra hard to find out who was requesting it so that I could know that I do not know either of them and therefor could not be accused of a COI in the dispute. Technical 13 (talk) 11:40, 31 May 2013 (UTC)

I understand the concern, "I do not want to offer a third opinion on a dispute where I'm familiar with either person currently involved." But that's easily addressed by requiring that the reporter mention the two people involved. And it's a small issue to begin with; someone beginning to provide a 3) is sure to see the names of the persons involved very quickly, even if we don't add the above requirement. --Elvey (talk) 02:14, 5 June 2013 (UTC)

I'm one of the most active volunteers at 3O — over 550 edits there and well over a hundred opinions given — and I believe things are fine just the way they are. The project places an ethical obligation on volunteers to be neutral, and the no-sig requirement is really to just help volunteers remain neutral in giving opinions by not knowing who asked for it. In truth, it's usually pretty obvious who made the request, either by the way the request is stated or by the fact that one or the other of the editors says at the article talk page that they're going to ask for a 3O or says that they've done so. The requirement is just a tiny bit of help, nothing more. I'd be opposed to making it more anonymous, however. For one thing, it's probably fruitless for the reasons I've already stated, but more importantly nothing should get posted publicly at Wikipedia which cannot be attributed to the poster. Moreover, 3O is the most "lightweight" of the dispute resolution processes at WP and 3O's are nothing more than just that: opinions. An occasional one which is slightly biased by knowledge of who asked for it isn't going to do much harm, in the grand scheme of things. Regards, TransporterMan (TALK) 18:22, 31 May 2013 (UTC)

+1 The opportunity for abuse and confusion is too great. It wshould stay as is. We already have at least as much anonymity as is good for the encyclopedia. ~ — Preceding unsigned comment added by DGG (talk • contribs) 23:07, 31 May 2013 (UTC)

^ says DGG, not signing his message...the irony is appreciated, I assure you :) Theopolisme (talk) 23:07, 31 May 2013 (UTC)

It's the impact of the irregular, not the most frequent/regular/active 3O suppliers that I'm concerned about. The reason I am proposing better anonymity is not mitigated by the facts TransporterMan mentions, because they address what I see as very minor problems to begin with. Here's a situation where the weak anonymity is a more serious problem: It's common for one person involved in a 2-person dispute to follow the edits of the other. If one of them thereby notices the other requested a 3O, that person could ask an ally or meatpuppet or use a sockpuppet to respond to the 3O. Such a biased 3O goes a long way to supporting a determined POV editor. If Theo implements the feature I'm asking for, then the follower will likely only know of the 3O request once it's been taken on by a regular. If providing such biased 3Os is no longer easy, then 3Os become more trustworthy, and more valuable. Seems like a relatively certain, specific and compelling reason to me.--Elvey (talk) 02:14, 5 June 2013 (UTC)

I'm not sure that is entirely accurate... Of the disputes that I have followed, it is most often that the person in the wrong, who knows they are wrong uses a SOCK account. The person that is right knows there is something fishy going on and it goes to DRN. The people who help out and volunteer in the DRN, often check the backgrounds of all three people involved and see if there is any potential sockpuppetry or meatpuppetry going on and seem to have a high rate of detecting such things. The sock goes to SPI and the DRN case is closed appropriately. It is my belief that anyone knowledgeable enough to make a sock account to try and prove their point, albeit an extremely stoopid idea, likely has WP:3O on their watchlist and will note the 3O request anyways. So, this doesn't really offer any improvement to the system and like I said above causes an issue with putting reviewers under extra fire for playing favorites despite not knowing who initially involved. Now, if your idea was to make DRN more anonymous by not having the two disputing parties identified and leaving it up to the 3O responder to decide if they want to be anonymous or not, then I would support that proposal. The reason I would support that and not the other is because of where the discussion takes place. In DRN all discussion is localized to the noticeboard and there are often multiple disputes going on at any one time. This means there are multiple DRN volunteers that will skim over each topic and the likelihood of one of the more experienced ones noticing something is exponentially greater than just the one 3O responder on the article talk page. Technical 13 (talk) 12:24, 5 June 2013 (UTC)

Following a user's contributions and using an ally is relatively quick/easy compared to doing that and following 3O as well; 3O is quite active. The change I'm proposing in no way opens up reviewers to extra fire. Instead of addressing my proposal, you have twice put up straw men of other ideas that are NOT what I've proposed ("they would have to remove all of their signatures" and "...if your idea was..."), and then shot them down. (A straw man did open up reviewers to extra fire.) Congrats, those straw men are dead. So what? If their flaws were present in my proposal, surely you'd shoot at my proposal instead of your straw men. You claim to routinely know when someone "knows they are wrong" in a content dispute and yet you can't see inside their heads, and besides, it's certainly not true that most people in a content dispute who are wrong know they are wrong. There are a fraction (including some paid shills) who don't believe what they're saying, but they're certainly a minority. --Elvey (talk) 17:45, 5 June 2013 (UTC)

Also, it seems you missed my comment above, which I'll repeat:

I understand the concern, "I do not want to offer a third opinion on a dispute where I'm familiar with either person currently involved." But that's easily addressed by requiring that the reporter mention the two people involved. And it's a small issue to begin with; someone beginning to provide a 3) is sure to see the names of the persons involved very quickly, even if we don't add the above requirement. --Elvey (talk) (repost)

Also, noted that I've EDITED THE PROPOSAL because Theo's offer made it easy to simplify.

I see being OK with telling 3O requesters to sign 3Os with ~~~~~ to be anonymous, and opposed to actual 3O requester anonymity as advocating dishonesty. I see no other way one could have those views. --Elvey (talk) 17:45, 5 June 2013 (UTC)

Two problems concerning edit conflicts

Hi all,

besides edit conflicts being always annoying there are two things that bug me most:

1. When editing a single section of a project page (like this one, with many subsections and mucht text), after an edit conflict I'm confronted with the Wikitext of the whole page. When I edited somewhere in the middle of the page this makes it nearly impossible to locate my own changes in the second edit window and it's as painful to locate the correct section in the first edit window.
2. Even worse: I have set my preferences to show the "View templates on this page" list below the edit window. In the case of an edit conflict this list is located below the first edit window (therefore between the two edit windows). As it happens that this list grows very long (e.g. on this page) and since it remembers it's state (collapsed or uncollapsed) sometimes I also have to scroll very far to even reach the second edit window, making comparisons impossible (yes, I know, I could just collapse the list first, but I forget that most of the time).

Are there any settings / gadgets / custom CSS / custom JavaScript / whatever which solves these problems (at least partially)? I'd love to have

1. Only the section I'm editing visible in both edit windows.
2. The "View templates on this page" section as well as the "View hidden categories on this page" section hidden on edit conflict pages, I don't need them anyway on these pages.(I also thought about custom CSS for this, but it seems an edit conflict page has no special class or anything similar?)

Regards, --Patrick87 (talk) 01:01, 2 June 2013 (UTC)

• I betcha I could cook up a JavaScript (you use JavaScript?) that would search for ec-specific text, and hide the template links if it finds it. (Ever more bloat. Huzzah.) Let's see if WK or Theo or Technical can beat me to it... Ignatzmice•talk 01:30, 2 June 2013 (UTC)

That would solve at least part of the problem, although I had hoped for a simpler solution (since I try to keep my Wikipedia bloated up to a minimum ). Is there a clean way to do this in JS? If the JavaScript needs to be specific like hell and requires a lot of manual fiddling to select the correct links on the correct pages it would be an unsatisfying solution I'm afraid. --Patrick87 (talk) 01:39, 2 June 2013 (UTC)

@Ignatzmice: I'd be happy to, but so far I've sufficiently avoided JavaScript proficiency...I'm more of a server-side scripter myself, but I guess it would still be a good learning experience. WK/Technical: code away, I'll work on my own version and then compare it to yours once completed so I can learn something. :p Theopolisme (talk) 02:28, 2 June 2013 (UTC)

@Patrick87: Whooooooofff. Took me a while, mostly 'cause I didn't realize for a while that just reloading the EC doesn't refresh the scripts, so the changes I was making weren't showing up. But also, Theo, because I have no freakin' clue what I'm doing. Google and StackOverflow, that's how I roll. Anyway:

importScript('User:Ignatzmice/templateEC.js'); // linkback: [[User:Ignatzmice/templateEC.js]]

should do it. Ignatzmice•talk 03:01, 2 June 2013 (UTC)

That's some beautiful code, my friend. Now just selectively hide part of a textarea and you'll go far ;) Theopolisme (talk) 03:04, 2 June 2013 (UTC)

Wow, thanks! Looks easy in principle. Do you have any idea how well this works performance-wise? I could imagine scanning the whole body-content could be quite demanding? Will test it soon (but probably not until tomorrow). --Patrick87 (talk) 03:08, 2 June 2013 (UTC)

It works, performance-wise. No idea about detailed milliseconds—might depend on the size of the page, might not. (The notice is at the top.) Maybe WK might have access to fancy-pants tools. I agree it's slightly worrisome that it scans the whole page, but like I said, it might quit after finding the notice—and can you think of an way it wouldn't?
Re: selectively hiding—I suppose I could look for the auto section summary, find that section, hide all above, find the next double-equals, hide all below—but that's just very pseudo pseudocode, and I need to get to bed. Someone else can try it, if they want. Ignatzmice•talk 03:16, 2 June 2013 (UTC)

Quick note: I tried to get it to only load on action=submit pages; that didn't work. I tried doing it without variables; that didn't work (though I don't mind that so much as the selective loading, just in case it does make a difference). If someone wants to take a peek at the history and let me know what I did wrong, go for it. But it doesn't matter that much. Ignatzmice•talk 04:03, 2 June 2013 (UTC)

Yo all. You don't have to search the whole damn page to find the template: just use a JQuery selector. $("div.mw-explainconflict") should do the trick. You'll want to read up about JQuery selectors (which are based on native CSS selectors, so they're extremely fast) in general; they're basically necessary to do any kind of user scripts on Wikipedia. Fortunately, JQuery comes with excellent API documentation. Writ Keeper ⚇♔ 05:26, 2 June 2013 (UTC)

Of course, if the contents of that script are all you're trying to do, you should be doing it through CSS directly, which would obviate any performance problems. I'll take a look. Writ Keeper ⚇♔ 05:29, 2 June 2013 (UTC)

Yo yourself. From what I can tell from the above thread, the other goal is to selectively "hide" some text in a text area. I have no idea if that's possible, but I imagine it would be a matter of editing the text area--storing its contents to a variable--using some sort of regex to "edit" the contents and make a capture group of the section the user was editing (via the diff tab?)--print only that text back out into the textarea--then letting the user edit it (just that section, in other words)--and then, once they press save, use some more capture-groupy magic to reinsert their updated text. I'm sweating and all I did was outline the functionality in a way that didn't even make much sense. Theopolisme (talk) 05:33, 2 June 2013 (UTC)

Also, I don't think that code will work, Ignatz: "templatesUsed" is a class, not an ID, so the correct selector would be $(".templatesUsed"). Writ Keeper ⚇♔ 05:39, 2 June 2013 (UTC)

You'd think, wouldn't you? But I found that #templatesUsed worked, and .templatesUsed didn't. It is also the ID of one of the divs or spans or something within the larger one. Who knows. Ignatzmice•talk 12:16, 2 June 2013 (UTC)

Okay, I think the CSS for hiding the templates used should be:

.mw-explainconflict ~ #editform .templatesUsed{display:none;}

. Put that in your common.css page and it'll get rid of that with no performance issues. Writ Keeper ⚇♔ 05:44, 2 June 2013 (UTC)

Ah, the sibling selector! Now I was searching for any class or ID of a parent I could use, but I didn't think of this CSS selector I never used before. --Patrick87 (talk) 05:59, 2 June 2013 (UTC)

Yeah, I knew that a sibling selector existed, but I had to look up its syntax. :) Writ Keeper ⚇♔ 06:03, 2 June 2013 (UTC)

Just put it into my de:User:Patrick87/global.css, works perfectly. Thanks again! --Patrick87 (talk) 16:27, 2 June 2013 (UTC)

(late to the party) In the above example, ~ is more correctly described as the general sibling combinator - it's a combinator, not selector, because it combines two selectors; and "general", since there is also +, the adjacent sibling combinator, which is better known, since it was introduced with CSS 2. --Redrose64 (talk) 20:10, 4 June 2013 (UTC)

Goddammit, you're right. Seems to load much faster, too. Ignatzmice•talk 12:16, 2 June 2013 (UTC)

S'why Jimbo pays me the big bucks, man. Generally speaking, any time you can do something through CSS directly, you should, since the CSS will load instantly and the equivalent Javascript will nearly always have a noticeable delay. the very barebones tools that CSS provides are also great for programmer discipline. Writ Keeper ⚇♔ 15:51, 2 June 2013 (UTC)

(Ironically, I just got an edit conflict.) And just hiding part of the text isn't a solution, since the way it works now your edit conflict is far more likely to cause other edit conflicts, since you are forced to edit the entire page, rather than the section, greatly increasing the risk of a conflict. I personally just hit the back button, cut my text, reload the page, and try the section edit again (with the text I paste back in). Is there any reason the code can't be changed to no longer escalate edit conflicts to the page level ? StuRat (talk) 05:46, 2 June 2013 (UTC)

Yes, and it's a problem that faces any user script, too: how do we programmatically know what section you were editing? I'm not sure there's a way to figure that out. (Well, that shouldn't be insurmountable on the server side, but it might be insurmountable for us user script plebs.)Writ Keeper ⚇♔ 05:48, 2 June 2013 (UTC)

Some edit-conflicts are caused by deleting/shifting text, or inserting subheaders, and the full-page display can help reveal when the section headers have changed, as when a re-edit accesses a different topic ==header==. -Wikid77 06:43, 5 June 2013 (UTC)

Couldn't you just look at the diff (that is shown when you edit conflict), grab some of the "+" text, and re.find (or whatever the javascript equivalent) in the text area? Then just match the == before and after it to get section boundaries. Not going to work *all* the time, but seems like it would cover a majority of the cases. Theopolisme (talk) 06:20, 2 June 2013 (UTC)

Not really, because we have no guarantee that your post is uniquely yours (in other words, that the text the method finds is the text you added, rather than someone else's). Think of any place on ANI or a village pump where !votes happen: new postst that are an exact duplicate could easily happen there, if one is just saying "'''Support.'''" or something. (Yes, signatures will usually resolve that, but that's still not a guarantee, and since it will weird the hapless use out to a significant degree, I don't think that's a good thing to ignore.) Moreover, that still doesn't help with SuRat's point, since that still doesn't let us submit a new API query with only the edited section; we still have to submit the entire page. Plus, that's just a shitty way of doing things, aesthetically speaking. Writ Keeper ⚇♔ 06:50, 2 June 2013 (UTC)

• Resolution of edit-conflicts is a 3-revision merge: And so a condensed edit-conflict preview would require comparing your changes to your prior revision, then comparing the newer revision against your prior revision, and then excluding the common sections, even if out-of-sync by one line all the way down the page. Instead consider how simplistic the full-page preview is: it shows the full latest revision versus your update to the full prior revision, with no attempt to merge the two at all. The auto-correction is not hard to do, but it can be confusing at a human level, of side-by-side comparisons better done by machine algorithms, as merging revision-C after revision-A with revision-D after revision-A, while allowing for other intermediate revisions called "revision-B" after revision-A. Unless all 3 revisions (A/C/D) are compared, then the edit-conflict cannot be accurately reduced to a few sections, because even small changes intended for the prior revision might seem very different against the latest revision. However, there could be a special-case counter, as for less than 5 changes, to show those limited sections, but auto-merge to submit the full page after edit-conflict. -Wikid77 (talk) 06:43, 5 June 2013 (UTC)

Tracked in Phabricator
Task T6745

• Regarding problem number 1: Just checked Bugzilla and found that it was already reported back in 2006. I hope we can catch the attention of a developer, since changing this directly in MediaWiki would be the best solution after all. --Patrick87 (talk) 15:53, 2 June 2013 (UTC)
  • Yep, looks like Brion had a similar concern to mine in comment 6. Writ Keeper ⚇♔ 16:01, 2 June 2013 (UTC)
    • I guess the question is, "Is this really necessary?" Flow will make edit conflicts things of the past--so why waste time building fixes to handle them in a system that will soon be unused on Wikimedia sites? Theopolisme (talk) 16:12, 2 June 2013 (UTC)

"Flow will make edit conflicts things of the past"? i thought flow only pertains to talk pages, no? conflicts happen in article space also... peace - קיפודנחש (aka kipod) (talk) 16:23, 2 June 2013 (UTC)

Mainspace edit conflicts are already handled quite well, all things considered--while they could be improved, that wasn't what this thread was specifically about. Theopolisme (talk) 16:31, 2 June 2013 (UTC)

• Mainspace conflicts can be horrific, as when trying to edit a hot-topic article, such as latest disaster or notable criminal case or such. Again, people should section-edit, then preview, copy new text, and then re-edit quickly to paste/save text (see essay: wp:Avoiding edit conflicts). -Wikid77 06:43, 5 June 2013 (UTC)

New notifications don't get attention of new users like the Orange Bar of Doom did

Recent experience indicates that the new notifications system doesn't get new users' attention nearly as well as the Orange Bar of Doom did. I found that a newly registered user had replaced most of the content of a stub article with a copyvio, so I removed the content and wrote a little "welcome" essay on the user's talk page. The user came back and recreated their earlier content with an edit summary ("did not save the first time for some reason tried it again") that indicates that they didn't see my user-talk message and have no idea what happened. I have to assume that this newbie hasn't noticed the rather subtle notification of a talk-page message, and they haven't enabled email. I've posted a warning on the talk page, but warnings and other messages to newbies are useless if the users (who presumably don't even know they have talk pages) never see them. --Orlady (talk) 03:55, 2 June 2013 (UTC)

• No shit, really? sighs... Ignatzmice•talk 03:59, 2 June 2013 (UTC)
  • Yep I have noticed that too. Kumioko (talk) 04:07, 2 June 2013 (UTC)

• Need top maintenance-tag to alert editors: The failure(s) of the user-talk system have been a problem for years, and we should not rely on MediaWiki software upgrades this year to fix it (after further user-talk downgrades), but instead, create a useful tag-box at the top of the article, especially if multiple editors were updating the page. I suggest a "{Concerned}" tag-box which would state, "Recent edits to this page have raised concerns; see Talk:Xxxx#Concerns" and have that link to header "#Concerns" or a header named by parameter {{{1}}}. Hence, even a new editor could redisplay the page, then see the top Concerned tag-box, and read the talk-page link to "==Concerns==" about adding the recent copyvio text. A {Concerned} tag-box should have been developed years ago, as a general notice which even new editors, or editors whose user-talk has been re-MediaWikified, could read as an alert to their edits. -Wikid77 (talk) 12:06, 2 June 2013 (UTC)

  Urgh, not more maintenance tags... . However, what you propose are really communication tags, not maintenance tags. What maintenance does such an article need? Since the edits that raised concern have already been undone, the only thing a wikignome finding the tag needs to do is remove the tag! I'm not keen on littering articles with little messages to get the attention of just one or two people editing it. If there are many editors making the same "bad" edits, the page needs an editnotice. Editnotices get the attention of editors without disturbing readers. There's also a strong risk of such tags being left on the article for years (the template could be coded to cause it to disappear from the rendered page after a week or two, though it would still be in the wikitext). – PartTimeGnome (talk | contribs) 00:21, 3 June 2013 (UTC)

The "maintenance" needed would be to remove the copyvio text if re-added (as explained at the related talk-page link). However, an edit-notice warning of copyvio would also help to deter the active editor(s), but unfortunately, give no alert to readers who might think the copyvio text could be copied, or was approved by "wiki-management". A tag-box template, as {Concerned}, would cover more options, formally logging the copyvio event, and also catch the attention of the editor who had noticed the "old revision" was still there "unchanged" but a {Concerned} tag-box would instead get the attention of the editor, as most definitely a change in the article's appearance after the copyvio text had been removed. Many people would be alerted to the issue. In a sense, working on Wikipedia is like a massive multiplayer chess game, where the strategy involves making moves in combination with all users, including new editors, old editors who fix copyvio problems, people who read an article wondering about copyvio, and people who want to copy an article (unaware copyvio text has been added). Adding a tag-box template is a move to make advances with numerous users, where many users also know how to easily remove the tag-box when outdated. -Wikid77 22:29, 5 June 2013 (UTC)

• Recent experience is not quantitative data, or even reliable qualitative data; it's the plural of 'anecdote' ;p. I'd note that clickthrough rates with the OBOD were pretty weak too. However: as far as I know there is some work being done to A/B test clickthrough rates and find out exactly how many people it grabs or misses, and hopefully iterate on the design from there. Ironholds (talk) 13:05, 2 June 2013 (UTC)

+1. as my teacher used to say: " 'anecdote' is not the singular form of 'data' ". we had plenty of cases of new users missing or ignoring the old "you have a message" bar. it is possible that the new notification is less visible, and it's also conceivable that it's more visible, or just equally as visible. pointing to one (or 5) case(s) where the new notification was ignored proves very little, considering the aforementioned fact that the old notification was also ignored occasionally. it's hard to think of a good way to produce reliable data for this question. peace - קיפודנחש (aka kipod) (talk) 16:00, 2 June 2013 (UTC)

• The user could have had javascript turned off. If I understand correctly, all the user would see was the (0) at the top of the screen turn into a (1) as the little orange bar is not fully integrated into Echo to make it HTML, which I've heard the developers are working on. In the mean time, I think a better way to notify the non-javascript users by turning from a (0) to a bolded (1) or (2). FallingGravity (talk) 23:34, 2 June 2013 (UTC)

  The "1" already appears in bold with a red background without the use of JavaScript. The developers fixed that a little while back. However, I still don't see the "You have new messages" orange bar that users with JavaScript see. I suspect many users without JS don't realise what the red number signifies and ignore it. (Or perhaps they try clicking it once, see just a trivial notification, then never look again, not realising it can tell them something more important.) We definitely need the orange bar available to non-JS users since it is a much clearer indication that the user has messages. I'm glad to hear the developers are working on this, or was what you heard only about highlighting the "1", which has already happened?

  I've added a note to Wikipedia:Notifications/FAQ#What happened to the orange bar for talk page messages on Wikipedia? to say that the orange bar requires JavaScript. – PartTimeGnome (talk | contribs) 00:03, 3 June 2013 (UTC)

  Ah yes, I had experimented with the disabling of the javascript a while back. Making the small orange bar HTML was mentioned by User:Edokter, over here. FallingGravity (talk) 20:32, 3 June 2013 (UTC)

  I saw that comment (it was a reply to me!). That was when the new message indicator was just a gadget. The developers have now integrated it into Echo, but it still requires JavaScript. I'm guessing they think no one needs to talk to non-JS users... – PartTimeGnome (talk | contribs) 21:38, 3 June 2013 (UTC)

Notifications error in calculation of yesterday

I've just noticed that when Notifications shows "Yesterday", that's not always true. From top to bottom, I have notices which give dates/times as follows:

• 06:41
• Yesterday at 05:14
• Yesterday at 22:54
• Yesterday at 21:21
• Yesterday at 19:25
• Yesterday at 17:45
• Yesterday at 13:43
• Thursday at 16:58

Notice in particular that the second seems to be earlier than the 3rd-7th. The true dates/times of the relevant edits were as follows:

• 06:41, 2 June 2013 (UTC)
• (see below)
• 22:54, 31 May 2013 (UTC)
• 21:21, 31 May 2013 (UTC)
• 19:25, 31 May 2013 (UTC)
• 17:45, 31 May 2013 (UTC)
• 13:43, 31 May 2013 (UTC)
• 16:58, 30 May 2013 (UTC)

There are two problems here. The first is that edits which were on Friday 31 May are shown as "yesterday" - today is Sunday 2 June. The other is that this new "... thanked you for your edit on ..." doesn't show in the relevant user's contributions, but I'm certain that it was 05:14 1 June, because that user made no edits on 31 May, but they did make an edit to the page named in the "thanked you" message at around the same time on 1 June. --Redrose64 (talk) 08:38, 2 June 2013 (UTC)

I suspect they used a very crude algorithm to decide what constitutes as 'yesterday', namely between 24-48 hours. — Edokter (talk) — 12:55, 2 June 2013 (UTC)

Redrose64, you are right about the date of that thanks. CSB radio thanked you at 05:14 on 1 June. See Special:Log/thanks. – PartTimeGnome (talk | contribs) 00:30, 3 June 2013 (UTC)

Might be worth to send a software bug report to the 'Bugzilla' bug tracker by following the instructions How to report a bug, in this case under the product 'MediaWiki Extensions' and the component 'Echo' (You can use this direct link if you have a Bugzilla account). This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance! --AKlapper (WMF) (talk) 09:29, 3 June 2013 (UTC)

Interesting Edit conflict failure.

I removed a comment of J with this edit. I got an edit conflict, but it only showed a blank line added a paragraph or so above my post but it did not show J's post. AutomaticStrikeout restored the comment with this edit a short while later. So, somehow I got what I thought was a "fake" edit conflict, but it wasn't and removed the previous editor's comment. Technical 13 (talk) 12:34, 5 June 2013 (UTC)

(edit conflict) (conflict against new thread added below during edit-preview)

• Some edit-conflicts are false, so re-run a Show-changes diff: Some edit-conflicts are correctly noted, but others are not, and re-running a "Show changes" can pinpoint the differences, plus check the recent history, such as with "limit=5" to list the prior 5 revision entries. I wish the "fake edit-conflicts" were just pilot error, but unfortunately, we have massive evidence that Wikipedia's edit-screen interface is broken, and needs to be fixed not abandoned, like having a bus where the doors do not open at some bus stops, and just buying a new bus with a simple door, rather than fix the original bus. I am hoping people can see that changing Wikipedia into a WYSIWYG "chalkboard simulator" is not the way forward, because pages, including talk-pages, are word-processing documents which use a macro scripting language where what-you-see ("WYS") is the template call or function call or calculation, and what-you-get ("WYG") is the computed result of calculating/typesetting the template's output. The WYSIWYG interface is better for young children, who want to scrawl on a chalkboard and edit at that level, whereas Wikipedia can support adults who use transformations of macros into text which does not appear in the original language, such as {{convert|45|ly|km mi}} yielding "45 light-years (4.3×10¹⁴ km; 2.6×10¹⁴ mi)" where the word "light-years" does not even appear in the input data. Anyway, the path forward is to fix edit-conflict, to fix the bus doors to open at every stop for every passenger, not get a new bus with a simple, small door which does not allow passengers to carry packages (or babies) onto the bus. -Wikid77 (talk) 13:40, 5 June 2013 (UTC)

Citations button not working

There is a "Citations" button next to the "Show changes" button when editing. It invokes a bot and I presume it is supposed to help with completing citations. At present it is adding an "f" character to the beginning of the edit buffer... Mirokado (talk) 22:16, 5 June 2013 (UTC)

The "Citations" button you refer to is enabled at Special:Preferences#mw-prefsection-gadgets with "Citation expander: Automatically expand and format citations (uses "Citation bot")." The added "f" is discussed at User talk:Citation bot/Archive1#The bot is trying to add an f word with every edit. PrimeHunter (talk) 22:39, 5 June 2013 (UTC)

Thanks! I'd forgotten all about that option. --Mirokado (talk) 22:44, 5 June 2013 (UTC)

Did some major glitch just happen?

My skin was changed, all my preferences are different and my giganto watchlist has disappeared. Before My Ken (talk) 23:25, 5 June 2013 (UTC)

Also, the latest edit shown in my contributions is from 2009. It looks like we're working from a back-up? Before My Ken (talk) 23:30, 5 June 2013 (UTC)

I haven't noticed anything. Your account hasn't edited since 2011 and its user page redirects to User:Beyond My Ken. Did you log in to the wrong account? PrimeHunter (talk) 23:31, 5 June 2013 (UTC)

Yes, I did, and I just discovered it seconds ago. I think that I got logged out on Commons and logged back in there using the wrong account. So sorry for bothering everyone. Beyond My Ken (talk) 23:34, 5 June 2013 (UTC)

TALK2: Talk-pages with paragraph edit

Although wp:FLOW has its own plans, what we have wanted, for years, is to simply go to a long talk-page, and edit by paragraph (each marked "[e]"), just one at time in those cases, to either change the paragraph or reply. Note this is just one mode of access, where also, the original ability to edit the whole talk-page and reply to several topics, during one edit, would still be supported. However, note that paragraph-level edits would still require automatic-merge for edit-conflict of 2 replies, such as FIFO (first-in, first-out), where the 2nd reply after a paragraph would get inserted after the 1st reply, and in fact, a 3-person edit-conflict would insert reply3 after reply2 (after reply1).
So, imagine a talk-page with numerous [e]'s down the page, at each paragraph, and perhaps have a Special:Preferences option to put "[e]" at the left-side of talk-page text, rather than as all right-side [e]'s. Now, paragraphs would be any ":" or "*" or "#" indent-mark or blank-line break, or perhaps a Special:Preferences to also mark any text break (newline) as a point to show "[e]" to edit that separate line. I understand the paragraph-level talk-page is not the same as WYSIWYG-edit, and paragraphs generated by templates (or Lua script modules) would limit access to the top of the template call, but it would be a format that even many new users could handle, by keeping the edit focused on one paragraph at a time (until users were more comfortable with the current section-level [edit] of "==Header==" or whole page). I think that would be fantastic, and solve the new-user frustration about long talk-page texts. Also, by inviting edits to just one paragraph at a time, then edit-conflicts would be limited to just one small portion of a talk-page, as much easier to auto-merge and resolve. After talk-pages, then perhaps introduce paragraph-edits to articles, with an option to just edit the whole page but position initial cursor at that paragraph. Does that sound useful? If so, we can move this thread to a wp:VPR proposal thread. -Wikid77 (talk) 11:07, 4 June 2013 (UTC)

This looks like micromanagement. Although that is not necessarily bad, I think that this would add a new level of complexity in a system that borders on being too complex already. What you are suggesting is the same concept of Liquid Threads, which although I wasn't around for the discussion on that, apparently didn't get consensus. Technical 13 (talk) 12:10, 4 June 2013 (UTC)

Instead, "micromanagement" is a style of planning, organization and control (POC) which dictates excessive commands at low-level operations. Also, wp:LiquidThreads is a limited message-box system, which could spread a 30-line conversation, with 12 replies, into four screens of scrolled message-boxes, where replies could only be appended onto one box at a time, with no limited ability to redact insults. Instead, listing the paragraph-edit buttons (as "[e]") would simply extend the "[edit]" feature at every paragraph and could probably be implemented within a few weeks, based on treating each "[e]" segment as if it were a "==header==" with all segments numbered in order. Sometimes the largest feature improvements can be made, quickly, with the simplest of software changes. -Wikid77 (talk) 14:23, 4 June 2013 (UTC)

I've just checked at MediaWiki.org (where LiquidThreads is installed), and I can edit other users' comments to redact personal attacks without a problem. You might be confused with the proposed Flow discussion system, for which Jorm is planning to restrict the ability to edit others' comments to administrators only. – PartTimeGnome (talk | contribs) 23:14, 4 June 2013 (UTC)

I guess others imposed limits on wp:LiquidThreads, where the edits to redact or append text into a message box were reverted as "improper style". -Wikid77 04:43, 7 June 2013 (UTC)

• No, what you have wanted is that. I've got no particular interest in being able to edit paragraph-by-paragraph exclusively, I think it would be excessively disruptive, and I think it would be a total waste of our time to discuss a feature that will be overwritten by Flow anyway. What you're asking is for the community and the foundation to play chicken...over paragraph editing. Ironholds (talk) 00:27, 5 June 2013 (UTC)

The paragraph-edit buttons (as "[e]") would simply extend the "[edit]" feature at every paragraph, for use with the current sophisticated talk-page structure, rather than the narrow, limited wp:Flow edits. Also, it could be extended to apply to paragraph-level editing of article texts, while using the full macro scripting language with markup for text styling, and templates for sortable tables, infoboxes, wp:charts, and Lua script modules to allow smart templates to help proofread text during edit-preview. -Wikid77 (talk) 04:43, 7 June 2013 (UTC)

Screenshots in talkpage discussion

With the usual apologies-with-humble-request-to-be-directed-elsewhere-if-this-isn't-the-right-place: I am involved in a discussion of how certain markup affects line breaks and text justification in the final, formatted version of articles seen at various zoom levels and so on. How would I insert screenshots into the discussion? It seems weird to upload images to the Wikipedia-never-forgets image repository (alongside the Mona Lisa and so on) for this self-referential purpose -- or would that be that OK? EEng (talk) 13:27, 5 June 2013 (UTC)

I've found uploading them to commons is the norm. I believe there is a category to tag them with if you upload them to enwiki and am not sure if there is such a thing on commons. Technical 13 (talk) 14:27, 5 June 2013 (UTC)

Uploading such images to commons makes no sense at all, as there is no way they could be useful to another project where the talk page discussion is not taking place. Just upload them locally.—Emil J. 14:59, 5 June 2013 (UTC)

I've actually used one to describe extension/core problems to devs on mw: before, so saying there is no way they could be useful elsewhere is stretching the box pretty thin... Technical 13 (talk) 15:29, 5 June 2013 (UTC)

Commons is, as T13 says, the norm--from Wikipedia:Software screenshots, if the screenshots are of free software (which wikipedia is, sans logo), they should be uploaded to Commons. When you upload them to Commons, be sure to tag them with commons:Template:Wikipedia-screenshot, which includes the Wikimedia logo caveat. Theopolisme (talk) 15:50, 5 June 2013 (UTC)

The page you linked to (which, anyway, is not even a guideline) is irrelevant. It discusses screenshots of software to be used as illustrations in articles on said software. Of course these belong to commons, just like most other media used in articles, barring legal issues. The OP is talking about something completely different: screenshots of a Wikipedia article used in a discussion on its talk page related to formatting changes in the article.—Emil J. 17:11, 5 June 2013 (UTC)

Precisely. While in principle article Talk discussions are filed away along with everything else in the Giant Grand Complete History of How Wikipedia Got This Way, a screenshot that's part of a minor side discussion on one article will be of no lasting use (especially the one I will be needing in the present situation -- I assure you) and since images are way larger than text one just wonders if there's somewhere to put such a screenshot such that it will silently evaporate sometime in the middle future. Otherwise, Emilj, by "locally" do you mean to en-wikipedia, or do you mean something else? EEng (talk) 18:20, 5 June 2013 (UTC)

I meant to English Wikipedia, yes.—Emil J. 20:06, 5 June 2013 (UTC)

Just use a third-party service like imgur, then. Theopolisme (talk) 23:53, 5 June 2013 (UTC)

What's wrong with me? Of course. Thanks. EEng (talk) 00:11, 6 June 2013 (UTC)

On concern regarding external hosters: Sooner or later they delete graphics and while it might seem some simple screenshots will never ever be needed again, nothing is more frustrating than finding an archived discussion (that seems relevant to a problem oneself might have one day) with all images unavailable and therefore being not understandable anymore. --Patrick87 (talk) 08:05, 6 June 2013 (UTC)

stats.grok.se /en server issue

On all pages, I've been getting "internal server error" on stats. Only on stats. I have Firefox 21.0, so when I go to Tools/Web Developer/Page Source, that also flips to "internal server error" — Maile (talk) 15:38, 6 June 2013 (UTC)

 Fixed - Henrik has resolved this. — Maile (talk) 21:44, 6 June 2013 (UTC)

Modern skin-Preferences-Gadgets tab is gone

My WikiEd disappeared between edits, so I went to find Gadgets...gadzooks!, it's gone, too. — Maile (talk) 17:06, 6 June 2013 (UTC)

And now it's all back. — Maile (talk) 17:08, 6 June 2013 (UTC)

VisualEditor weekly update - 2013-06-06 (MW 1.22wmf6)

Hey all,

Here is a copy of the regular (now every week) update for the VisualEditor project. This is so that you all know what is happening, and make sure you have as much opportunity to tell us when we're wrong and help guide the priorities for development and improvement:

VisualEditor was updated as part of the wider MediaWiki 1.22wmf6 branch deployment on Thursday 6 June. In the ten days weeks since 1.22wmf5, the team worked on new features ahead of VisualEditor's launch as the default way users will edit our wikis in beta.

The most noticeable change for users is that it is now possible to set, edit and remove the categories that a page belongs to and it's "default sort" key, as part of the new "page settings" dialog that can be opened from the button on the toolbar. For now, this dialog covers categories and a simple listing of language links, but will be expanded to cover other "meta-data" like a page having the table of contents disabled, and integration with Wikidata's language links system. Work also continued on the other three critical areas ahead of the release - Templates, References and Images - and we hope to release these in the next week or two.

The way that known browsers are supported changed slightly; browsers are now only blacklisted if we know that they cause significant problems, like Internet Explorer version 8 and below. If your browser is not known, you will get a notice alerting you to this issue (38128). We have added further support in our back-end for multi-character "grapheme clusters", which means that wikis that use extended ("non-BMP") Unicode characters can now work (48975). The left and right arrow keys now move in the correct direction in RTL environments (38546).

A complete list of individual code commits is available in the 1.22/wmf6 changelog, and all Bugzilla bugs closed in this period on Bugzilla's list

Per the MediaWiki deployment roadmap, this should be deployed here on Thursday 13 June.

Hope this is helpful! As always, feedback gratefully received, either here or on the enwiki-specific feedback page.

Jdforrester (WMF) (talk) 22:07, 6 June 2013 (UTC)

Green highlighting of changes since last visit doesn't work anymore

In revision history listings of pages on my watchlist, the highlighting of edits since I last visited the page doesn't work anymore (using Monobook). Thanks for any help... AnonMoos (talk) 19:50, 25 May 2013 (UTC)

Today, I'm having a similar problem in Vector. For me also, the green highlighting in edit histories is gone, and I would very much like to have a way to get it back. Instead, what I see now is a small bullet point at the beginning of each entry, and the point changes from green (new) to blue (previously visited), with these dots also on my watchlist. For me, it's fairly difficult to see the difference in color of the small dot. --Tryptofish (talk) 20:21, 25 May 2013 (UTC)

Thanks for mentioning the green dots (I could have gone a looong time without figuring that out for myself). I need to put my face up close to the screen and squint to make use of them, so I agree there definitely needs to be a change... AnonMoos (talk) 21:07, 25 May 2013 (UTC)

I noticed it 2+1⁄2 hours ago; I was wondering how long it would take people to complain. This is the edit; there is a link in the edit summary to the relevant discussion. --Redrose64 (talk) 21:11, 25 May 2013 (UTC)

(edit conflict) Yes, they are indeed difficult to see (in terms of color). I don't mind, however, if the change remains in place, just so long as there is an opt-in workaround for those of us who would like to put something in our preferences that restores the green-font "changed since your last visit" notice on the edit history pages. --Tryptofish (talk) 21:14, 25 May 2013 (UTC)

(edit conflict) (edit conflict) (edit conflict) it's because of this edit. i did not see it discussed anywhere, and i think it should be reverted, or at least discussed. for now (i.e., until it's reverted), you can undo it for yourself by adding to Special:MyPage/common.css the following line:

span.updatedmarker { display: inline; }

i do not think it's an acceptable solution, though. i think this edit should just be reverted. IMO it is borderline sabotage (although i'm sure this was not the intention). peace - קיפודנחש (aka kipod) (talk) 21:16, 25 May 2013 (UTC)

(edit conflict)(sorry about all the ecs) Per Redrose's link, there was "discussion" here: WP:Village pump (proposals)#"Updated since last visit" markers, where I'm about to make a cross-notice. --Tryptofish (talk) 21:19, 25 May 2013 (UTC)

yes, i had so much trouble saving my edit that i did not read carefully the previous addition to the section. i now read the discussion, and i could not find anywhere in the proposal a mention of "oh, and by the way, i am going to hide the updatemarker". all i saw was a discussion of blue vs. green dots, to which i am pretty agnostic. peace - קיפודנחש (aka kipod) (talk) 21:22, 25 May 2013 (UTC)

to clarify: the actual edit did some things which were not at all discussed in the proposal. only those things (i.e., hiding the green "changed since your last") should be reverted, not necessarily the whole edit. peace - קיפודנחש (aka kipod) (talk) 21:26, 25 May 2013 (UTC)

Gazillions of ECsTo restore it like it was, add the following to Special:Mypage/common.css:

span.updatedmarker {
    display: inline;
    font-style: italic; /* if desired */
    background-color: transparent; /* this makes the text colored (not highlighted); use if desired */
    color: #006400; /* green, not black */
}

But I agree that User:Edokter didn't really have consensus, and (like with the orange bar and Notifications) it wasn't clear that this new feature would remove the old one. I thought it would only change the color of the dots. Ignatzmice•talk 21:30, 25 May 2013 (UTC)

Thanks, both of you, very much! For me, the second of these fixes (the one from Ignatzmice) is the one that most exactly restores what I wanted back. Also, if one uses Vector, I think it's the "vector.css" file, rather than "common.css" that needs to be edited. --Tryptofish (talk) 21:37, 25 May 2013 (UTC)

Thanks, I always like trying to figure out these kinds of things! Common.css changes it for all of your skins; the specific ones change it only for that specific one. So long as you only use one skin, it's six of one, half-dozen of the other. Ignatzmice•talk 21:40, 25 May 2013 (UTC)

Woops, thanks. I changed both (12?). Anyway, I'm happy again. I'll also point out for future readers here that your instructions include "optional" parts, and I included those to get the same font color and format as before. --Tryptofish (talk) 21:44, 25 May 2013 (UTC)

(edit conflict) regarding the style, you are correct that "my" snippet does not restore it exactly to the way it was, while Ignatz's snippet does. "mine" actually restores it to the way i see it on other wikis, which i prefer personally. but this is really splitting hair - the main thing is to restore the message itself. as to vector.css vs. common.css: since the sabotage was done on Mediawiki:Common.css, i think it makes more sense to override it in the personal common.css. peace - קיפודנחש (aka kipod) (talk) 21:48, 25 May 2013 (UTC)

Reset code

Ok, for the non techies like me, what's the code to remove the dots (of any colour), please? NtheP (talk) 22:46, 25 May 2013 (UTC)

/* Hide reset button */
#mw-watchlist-resetbutton {
    display: none;
}
/* Restore default bullets */
.skin-cologneblue li.mw-changeslist-line-watched,
.skin-cologneblue li.mw-history-line-updated {
    list-style-type: disc;
}
.skin-monobook li.mw-changeslist-line-watched,
.skin-monobook li.mw-history-line-updated,
.skin-modern li.mw-changeslist-line-watched,
.skin-modern li.mw-history-line-updated {
    list-style-image: url(/w/skins/monobook/bullet.gif);
}
.skin-vector li.mw-changeslist-line-watched,
.skin-vector li.mw-history-line-updated {
    list-style-image: url(/w/skins/vector/images/bullet-icon.png);
}

— Edokter (talk) — 22:59, 25 May 2013 (UTC)

• NtheP seemed to be asking how to remove any dots. I would imagine that could be achieved with list-style-image: none;, but that's not working for me.... Ignatzmice•talk 23:05, 25 May 2013 (UTC)
  • That would restore the default HTML bullets. I do think he asked how to restore the original bullets. — Edokter (talk) — 23:11, 25 May 2013 (UTC)

(edit conflict) (edit conflict) (trying to answer the question: how to remove the dots in history. not sure if it's the same as Ignatz's answer, but if so, i guess it won't work...)

try

ul#pagehistory { list-style: none; }

this comes with zero guarantee...  : ( peace - קיפודנחש (aka kipod) (talk) 23:08, 25 May 2013 (UTC)

• I'm trying to make the newly appeared neon green dots on the watchlist go away and have tried several pieces of code above but none seems to work. Which script to use to make them disappear on the watchlist only? Victoria (talk) 23:15, 25 May 2013 (UTC)
  • You put the entire code in your User:Victoriaearle/common.css. — Edokter (talk) — 23:19, 25 May 2013 (UTC)
    • Got it thanks. Victoria (talk) 23:34, 25 May 2013 (UTC)

Yes thanks for that code to remove those stupid green dots. Lugnuts ^{Dick Laurent is dead} 09:16, 26 May 2013 (UTC)

Getting rid of any dots would be great but it's enough for me to be able to reset them to black and unchanging. Edoktor, thanks for posting the code. NtheP (talk) 09:23, 26 May 2013 (UTC)

Edokter, why did you change none; to none none; here? I would have thought that it had no effect. Is this some new syntax for CSS 3, rather like !important? --Redrose64 (talk) 10:42, 26 May 2013 (UTC)

list-style is a shorthand for list-style-type, list-style-image and list-style-position. In order to disable the bullet completely, the first two need to be set to none. Because there are two properties that accept none as a value, you need to specify it twice in the shorthand notation for both properties to be set. — Edokter (talk) — 11:09, 26 May 2013 (UTC)

I agree that list-style is a shorthand for the other three, it's in the CSS 2.1 documentation; but that documentation says nothing about the first value applying to the type, the second to the image and the third to the position. The general principle with CSS properties that accept multiple values is that the order that they are specified is unimportant.

That doc page states "A value of 'none' within the 'list-style' property sets whichever of 'list-style-type' and 'list-style-image' are not otherwise specified to 'none'. However, if both are otherwise specified, the declaration is in error (and thus ignored)." very near the bottom of the doc, and then explicitly states "a value of 'none' for the 'list-style' property sets both 'list-style-type' and 'list-style-image' to 'none'", with an example of such use. --Redrose64 (talk) 15:19, 26 May 2013 (UTC)

Is that the correct version, and is it still current? I've seen this fail in both Chrome and Firefox if only one none is specified. I also think that otherwise means being set to anythinng else the "none". — Edokter (talk) — 15:30, 26 May 2013 (UTC)

I can't seem to reproduce the bug though; one "none" seems to work (but two isn't an error). — Edokter (talk) — 15:38, 26 May 2013 (UTC)

It's the latest recommended version. At the W3C All Standards and Drafts list, there is a link Cascading Style Sheets (CSS) Snapshot 2010, which does yield a list of properties, but in there the entry for list-style points straight to the doc that I linked at 15:19, 26 May 2013.

There is CSS Lists and Counters Module Level 3, dated 24 May 2011, but that's described as a "Working Draft", so it's not final. It does give a better explanation of the none value. --Redrose64 (talk) 18:54, 26 May 2013 (UTC)

Last time I checked, the need for "none none" was because of an IE bug. Anomie⚔ 00:09, 29 May 2013 (UTC)

On a related note, is there some code that would get rid of the green highlighted "updated since my last visit" that appears in the history?--十八 10:53, 26 May 2013 (UTC)

.updatedmarker { display: none; }

— Edokter (talk) — 11:09, 26 May 2013 (UTC)

Thanks.--十八 20:52, 26 May 2013 (UTC)

Green bullets - accessibility

Instead of two different-color bullets, it ought to be a bullet vs. no bullet. It'd be much easier to make out the difference. —Designate (talk) 14:33, 26 May 2013 (UTC)

Can't see any bullets at all!

I'm stealing the thread here, but I can't see any bullets at all. I'm using Firefox 21.0 for Ubuntu Canonical 1.0. --Fama Clamosa (talk) 16:36, 27 May 2013 (UTC)

I also don't see any bullets but I'm assuming it has more to do with the fact I'm using the gadget that bolds the new entries on my watchlist than it does with the fact that I'm using the Vector skin from Firefox 21 on a Windows Vista laptop. Technical 13 (talk) 16:52, 27 May 2013 (UTC)

I've given this its own section heading, so you're not stealing the thread any more . – PartTimeGnome (talk | contribs) 17:01, 27 May 2013 (UTC)

I'm using the bold watchlist gadget, but I still see the bullets without a problem using both Vector and Monobook. It might be related to some other gadget; can you see the bullets in page histories and Special:RecentChanges when logged out? (Obviously you can't check your watchlist when logged out.) Or it might depend on the browser; which browser do you use? I'm using Opera 12.15 on Linux. – PartTimeGnome (talk | contribs) 17:06, 27 May 2013 (UTC)

You can't see them on the watchlist if you have enhanced recent changes enabled (aka Group changes by page in recent changes and watchlist), but you should always see them on history pages. — HHHIPPO 17:22, 27 May 2013 (UTC)

Thanks PartTimeGnome for editorial help. I just logged out and had a look at RC with the same result. I also disabled AdBlock Plus on en.wiki.x.io (just in case) with the same result-- no bullets. I see them on history pages. --Fama Clamosa (talk) 17:24, 27 May 2013 (UTC)

I don't see them on any pages in any browser on either account. I've checked Watchlist, RC, and page histories in IE7, as well as the latest version of Opera, Chrome, Firefox, and Safari. This T13 account has RC grouping on, but my ShoeMaker account doesn't, and there still are no green bullets. Technical 13 (talk) 17:29, 27 May 2013 (UTC)

Okay, so I got them to show up on my ShoeMaker account in all of the browsers I tested (IE7, Opera, Safari, and Chrome), but ONLY on my watchlist and histories (which was hard to get, I could only get it from the hist link on the watchlist page) did it work, still no green on RC. Technical 13 (talk) 17:51, 27 May 2013 (UTC)

Just to double-check: are we really talking about no bullets at all or about no green bullets? I just tried in all 4 skins, looks fine (FF 21.0, Ubuntu 12.4). When logged out, I still see bullets but of course no green ones. Anybody who really sees no bullets at all: could you try the Cologne Blue skin? — HHHIPPO 18:19, 27 May 2013 (UTC)

No green bullets. The icon used for the green bullet is hard to distinguish without using my magnifying tool. Of course, there are no bullets at all on this account, but I am using enhanced changes (which should remove the text declaring that new should have green bullets since they don't exist for that gadget). Technical 13 (talk) 18:30, 27 May 2013 (UTC)

• Bullet size: agree that they are really hard to see. I changed them to for myself.
• Text announcing green bullets: indeed that's wrong, but it's hard to remove it without removing the Mark visited button. Unless... is it possible to add html tags to MediaWiki:Wlheader-showupdated? So we could set display:none in enhanced mode?
• What's missing: so the only thing you don't see is green bullets when looking at RC in non-enhanced mode? Are you sure you found an edit that should have a green bullet? — HHHIPPO 18:58, 27 May 2013 (UTC)

• It is possible to add html tags to MediaWiki:Wlheader-showupdated, you can tell because there is already a <Span style=color: darkgreen; font-weight: bold;>green</Span> in there to change the color of the word green. I'm sure it will be a very rare circumstance to ever see a "new since last" revision in RC. Technical 13 (talk) 22:26, 27 May 2013 (UTC)

The tags are being worked on, see next sub-thread. To see a green dot in RC, what I did was purposely leave an updated page in the project namespace unvisited, and then filter RC for that namespace. There the traffic is not too much. — HHHIPPO 06:47, 28 May 2013 (UTC)

I've made an edit request → MediaWiki talk:Wlheader-showupdated#May 2013 Edit Request which should give span#id that can be used to display: none; (and that could probably even be worked into enhanced recent changes to automatically apply something similar). Technical 13 (talk) 10:51, 28 May 2013 (UTC)

This edit request has been fulfilled and you may now add

span#mw-wlheader-showupdated{display: none;}

to your common.css to hide this extra interface message. Technical 13 (talk) 19:32, 28 May 2013 (UTC)

Related changes bug

It still tells us that "Changes to pages on your watchlist are shown in bold," but they're actually now shown with the green bullet (even with the green bullets switched off in the watchlist). I'm guessing this is the same in Recent changes. FallingGravity (talk) 20:00, 27 May 2013 (UTC)

The message is fixed now, except that, like above, there are no bullets in enhanced mode. Plus, watched pages are still supposed to be bold if the corresponding gadget is enabled, but that's broken atm. — HHHIPPO 20:40, 27 May 2013 (UTC)

That's a different message: MediaWiki:recentchangeslinked-summary. That text has never been hidden. I changed the text, and the gadget to hide the text conditionally. — Edokter (talk) — 20:43, 27 May 2013 (UTC)

I know. Looks good. Could you set the same span around the watchlist message (but not the reset button)? Technically one should also set display:none for them in enhanced mode, but as long as the span is there people can do that locally. — HHHIPPO 20:50, 27 May 2013 (UTC)

Will get around to it tomorrow. Too late now. — Edokter (talk) — 21:53, 27 May 2013 (UTC)

Fixes not working in monobook...

I have tried all of the above codes in my common.css, and none of them have made the stupid green bullets go away. Is there help to be had? - The Bushranger _{One ping only} 04:48, 1 June 2013 (UTC)

Did you try using the "no green bullets" gadget? It worked when I tried experimenting with the monobook skin. FallingGravity (talk) 19:04, 2 June 2013 (UTC)

Re: Watchlist notice

Today, I noticed that on my watchlist at the top it now says "Pages that have been changed since you last visited them are shown with a green bullet." Is this only temporary? Or is there a way I can remove it?--十八 20:51, 7 June 2013 (UTC)

Permanent reflist

Hi.

Is it possible to add a permanent {{Reflist}} below my main edit box, so that even when I edit a section, I can see how references look like?

Best regards,
Codename Lisa (talk) 18:36, 4 June 2013 (UTC)

The way that you can do that now is just add in a {{Reflist}} to the article section you are editing, preview it to see how the refs look, and then remove it before you save your edit. postdlf (talk) 18:41, 4 June 2013 (UTC)

Yeah, it just needs a round of add and previewing, and a round of removing which can be forgotten, with catastrophic results. Thanks for the hack, which I knew by the way. Can we please stay on topic? Best regards, Codename Lisa (talk) 20:18, 4 June 2013 (UTC)

Yes, that should be possible, although it might be better to require a mouseclick to do it (more like an in-line page preview with a built-in reflist). Writ Keeper ⚇♔ 20:34, 4 June 2013 (UTC)

You will still not be able to see named references which were defined in other sections. A better solution is User:Anomie/ajaxpreview.js. --  Gadget850 ^talk 20:59, 4 June 2013 (UTC)

Thanks. Best regards, Codename Lisa (talk) 21:15, 4 June 2013 (UTC)

What I would like is not a permanent reflist, but a "Preview w/ reflist" button. I am constantly adding a {{reflist}} to check refs, then have to remove it, and once in a while forget to, which in more highly trafficed articles splats some number of users with a big red error. ~ J. Johnson (JJ) (talk) 20:52, 7 June 2013 (UTC)

Module:Infobox is now live

I have just now put Module:Infobox up live on the English Wikipedia. Please keep an eye out for any bugs, and report them to Template talk:Infobox. And a big thanks to Toohool for writing the code, and for WOSlinker for helping me to test it. — Mr. Stradivarius ^{♪ talk ♪} 09:35, 5 June 2013 (UTC)

It's clear from Template talk:Infobox that this has worked very well. Congratulations to all involved! -- John of Reading (talk) 07:00, 7 June 2013 (UTC)

"Sign your posts on talk pages"

Considering that many new users get confused by this, I think it would be worthwhile to no longer display it in mainspace, as I've suggested here. I'd like to know how this can be done in js, along with linking. Thanks, Cenarium (talk) 17:09, 5 June 2013 (UTC)

• Suppressing rulespam for everyone or user option: In general, the wp:rulespam has grown like kudzu, and the whole system needs to reduce the rulespam to a few lines and instead start wikilinking to rule-blurb pages, such as see: "wp:Explain PUMPTECH rules" rather than fill the screen with the same tired "rants" of issues to consider before replying. However, meanwhile, we need to help users suppress the messages, such as "Sign your posts on talk pages" etc. I also wonder how to suppress the View-Source diatribe ("You do not have permission to edit this page..."), which spans almost 2 screens of text, when trying to edit a protected page. -Wikid77 (talk) 21:18, 5 June 2013 (UTC)

the above rant seems somewhat disconnected from reality. i include the subject of this discussion, i.e. the standard talk page editnotice here, to aid the discussion:

where exactly do you see rulspam? in reality, this does exactly what you preach: it provides a link to a more elaborated policy page explaining talkpage guidelines, and very little else. i do not have strong opinion regarding the comment about the signature myself: if signbot is active on main talk space, i think it can be probably dropped without too many repercussions. however, using this lean and mean editnotice as an excuse for this long sermon seems slightly out of place. peace - קיפודנחש (aka kipod) (talk) 23:05, 5 June 2013 (UTC)

The proposal is about dropping the "Sign your posts on talk pages" bit when editing articles rather than article talk pages. – PartTimeGnome (talk | contribs) 23:24, 5 June 2013 (UTC)

I think the original poster is referring to the item in "edittools", i.e. the business that appears below the edit box:

– — ° ″ ′ ≈ ≠ ≤ ≥ ± − × ÷ ← → · §   Sign your posts on talk pages: ~~~~   Cite your sources: <ref></ref>

There is already a discussion on this at MediaWiki talk:Edittools. — This, that and the other (talk) 09:41, 6 June 2013 (UTC)

this, of course, makes perfect sense. there may be other markups which should be namespace dependent: e.g., "ref" and "reflist" on article space only, "noinclude" and "includeonly" on template space only, and maybe a couple others. i do not think edittools is currently clever enough to take the namespace into account, but it's pretty straightforward thing to teach it to do so. קיפודנחש (aka kipod) (talk) 18:58, 6 June 2013 (UTC)

<ref> and {{reflist}} are often used on talk pages. <includeonly> is used in Fetured Lists to trancslude the lead onto Wikipedia:Today's featured list.  Gadget850 ^talk 20:37, 6 June 2013 (UTC)

{{shrug}}. did not try to say that these wikicodes are never used outside their "natural habitat". i still think that "ref" and "reflist" are more likely to be used by mistake than intentionally outside article space, and "includeonly" and "noinclude" are more likely to be used mistakenly outside of template namespace. removing them from the charinsert box will not prevent anyone from using them - it will just remove a probably-not-what-you-meant button from the box. i can continue to live peacefully with them there on all spaces (just as i lived with the signature button in article space...) - i merely commented that teaching edittools to display a namespace-dependent list may have more uses, in addition to removing the sig button. peace - קיפודנחש (aka kipod) (talk) 21:24, 6 June 2013 (UTC)

Could a JS-savvy person or two please take a look at my post? — This, that and the other (talk) 08:12, 7 June 2013 (UTC)

Why is there a difference I cannot see?

See this edit. The diff demonstrates a real difference that I cannot see. Is there a hidden character, or another character that looks identical but is not so in fact? I've just requested some category moves and I want to make sure these all end up in the right place. -- Ohc ^¡digame!_{¿que pasa?} 03:23, 7 June 2013 (UTC)

Which browser where you using? I can't see a difference either, and I'm in Chrome 27 on Windows XP. -- ^(T) Numbermaniac _(C) 03:26, 7 June 2013 (UTC)

It's probably a different character format. Differences of any kind will ring up as a diff. Even of its the format.—cyberpower ^Chat_Offline 03:32, 7 June 2013 (UTC)

I find a hidden character at the end of the old version. The program I'm using calls it ASCII 26 (substitute character), but that may just be my program's way of saying "I don't know". Dragons flight (talk) 03:40, 7 June 2013 (UTC)

• Thanks. I had a suspicion about this, and tried replacing the characters one after another. Only by changing the last character did my regex tester react. I baffled as to how that "I don't know" got there. Humpf! :-( -- Ohc ^¡digame!_{¿que pasa?} 03:48, 7 June 2013 (UTC)

• It's a Unicode Left-to-right mark (U+200E). It occurs where the * is in "(Bundesliga*|Liga)/gi, '$1$2')". Johnuniq (talk) 03:50, 7 June 2013 (UTC)

• Thanks for the pointers. What enables you to see it? Just curious to know if there are any more such characters in my scripts – I occasionally get surprising 'failures' but with no apparent errors. -- Ohc ^¡digame!_{¿que pasa?} 05:56, 7 June 2013 (UTC)

Each row of a watchlist starts like this: (diff | hist) . . Example title*; 06:51 . .

The LTR (left-to-right mark) is just after the title (where * is shown). There are a total of four LTRs on each watchlist row—I don't know the details, but they are used to say "what follows is left-to-right text", and are presumably used because in some cases the preceding text might have been right-to-left. If you highlight and copy "Example title" you might accidentally also copy the LTR. That's often how it ends up in places where it should not be. I can see it because I use one of the many text editors that can show stuff like that (and I have a simple script that uses wget to get a particular revision of a page which I can use to perform a diff locally).

If you put a list of page titles here or on my talk, I will check them for non-printable characters. Johnuniq (talk) 07:19, 7 June 2013 (UTC)

On the test Wikipedia I once made a gadget (pretty outdated, don't use it) to expose evil hidden Unicode characters in the editing window, by temporarily converting them to HTML entities. It was pretty easy to copy/paste existing functions from it and other stuff to make a similar script at User:Splarka/diffreveal.js to show invisible Unicode in diffs (via history or "Show changes" button). The diff above shows as Bundesliga[U+200E] with it, for example. It could be adapted pretty easily to various needs. --Splarka (rant) 09:18, 7 June 2013 (UTC)

if you use chrome, i found the "Unicode Analyzer" extension 100% unobtrusive, and occasionally useful. it allowed me to see the problem in the very first diff (in first post) almost immediately. peace - קיפודנחש (aka kipod) (talk) 14:58, 7 June 2013 (UTC)

• Here's my technique. In the Wikipedia diff, copy the mystery text to your copypaste buffer, making sure that you also get a few extra characters at the start and end - this is to ensure that you get all the invisibles. Then go to Unicode Code Converter v7.05, and paste your text into the "Mixed input" green box. Then click the "Convert" button immediately above - all the grey boxes will then get filled in, in different ways. If I do this, the "HTML/XML" second grey box shows ll-(Bundesliga‎|Li - I then append that Unicode hex value to http://www.charbase.com/ giving http://www.charbase.com/200E for information about the character. For some reason, this technique doesn't work for diffs containing a   - they get decoded as regular spaces. --Redrose64 (talk) 19:18, 7 June 2013 (UTC)

  I guess you're using Firefox... Converting NBSP into a regular space in form fields is a very long-standing bug in Firefox (over 10 years old). It's why you sometimes see users make edits that change NBSPs into regular spaces if they're not ampersand-encoded. See bugs 194498 and 359303. – PartTimeGnome (talk | contribs) 21:21, 7 June 2013 (UTC)

Firefox and NBSP have an interesting inconsistent relationship. In FF20.0, I can currently edit forms containing them, paste them in, input them manually, and submit/save them. But, I can not copy them from Firefox's markup, forms, or javascript windows (prompt('nbsp','\u00a0');). This makes sense for most use cases, but is inconsistent with how other browsers work. --Splarka (rant) 22:46, 7 June 2013 (UTC)

HotCat / CatScan / AWB

I have used CatScan to find X number of articles that I want to add a new category to. Is there an easy way to add the category to all of the relevant articles usind HotCat or AWB? Or do I have to manually add to each and every article, which may be 100 or so and will obviously be a boring and time-consuming task. GiantSnowman 09:27, 7 June 2013 (UTC)

You can probably do it with AWB... It has the ability to pull all of the members of a category, save that list to a file, pull the members of a second category, compare the two and only keep the ones in both categories. It would be helpful if I knew what your CatScan query was... Technical 13 (talk) 11:35, 7 June 2013 (UTC)

I did it quickly late last night, but it was searching through Category:English football managers for all articles that are also in the subcategories of Category:Expatriate association football managers by country of residence. All relevant articles are therefore eligible for inclusion in Category:English expatriate football managers - and I intend to repeat it for all relevant nationalities. GiantSnowman 11:42, 7 June 2013 (UTC)

Yeah, you can do that with AWB... If you need someone to do it for you... Wikipedia:AutoWikiBrowser/Tasks is the place to ask. :) Happy editing! Technical 13 (talk) 13:15, 7 June 2013 (UTC)

Thanks, I'm not super-savvy with AWB (i.e. I keep to the basics!) but I'll have a play around. Thanks. GiantSnowman 13:18, 7 June 2013 (UTC)

To get your list for the subcategories of Category:Expatriate association football managers by country of residence you'll have to use a "recursive category" search. When I did it, I found that there are about 2550 pages in those sub-categories. When I cross referenced it with the Category:English football managers there was about 1250 articles in both... Technical 13 (talk) 13:23, 7 June 2013 (UTC)

Hmm, I'm sure my CatScan brought back just under 100 articles. One of us must be wrong! GiantSnowman 13:25, 7 June 2013 (UTC)

I'm not convinced that CatScan is accurate. I've never had any luck using it. Anyways, yes, one of our methods is wrong. :) Technical 13 (talk) 13:41, 7 June 2013 (UTC)

i am not 100% sure i understand what you are trying to do, but from what i saw, cat-a-lot is the ideal tool for the job. you might want to look at it (see Wikipedia:WikiProject User scripts/Scripts). it's a very powerful category-manipulation tool that was developed in commons. initially it operated on files only, but now it can handle any page. be warned - i did not test it in a while, and it's possible that one of the recent version upgrades broke it. if you do try it and find problems, please report (and, actually, i would also appreciate a report if you use it and find it useful). peace - קיפודנחש (aka kipod) (talk) 14:50, 7 June 2013 (UTC)

Module:String technical help requested

Hello all, I've posted a question at Module talk:String/Archive 1#Help needed and am hoping to get some help... If you know anything about the Module or Lua in general, please check it out. Thanks. Technical 13 (talk) 18:15, 7 June 2013 (UTC)

Regex

Hi I would like to replace every parameter containing specific word with something else. However I can't mange to build my Search string. For example I want to pick all those parameters:

{{{abcNAMEasd|}}}
{{{NAMEefg|}}}
{{{hijNAME|}}}

I obviously start with \{\{\{ and end with \}\}\}, but I can't figure out the look up. Please help. 79.176.217.170 (talk) 03:48, 8 June 2013 (UTC)

It sounds like you want this: {{{.*?NAME.*?}}}. And you don't need to escape curly braces in regex. Best — Mr. Stradivarius ^{♪ talk ♪} 05:14, 8 June 2013 (UTC)

Thanks, it works but still too inclusive, for example it will catch this as well:

{{{SomeOtherCarp|}}}
{{{abcNAMEasd|}}}

also I do need escape curly braces, at least in the variant used in notepad++ ;) --79.176.217.170 (talk) 05:42, 8 June 2013 (UTC)

Actually your variant works, I just changed the first any character to char, which fits my needs. Thanks. (btw have fun in mediations ;) ) 79.176.217.170 (talk) 05:52, 8 June 2013 (UTC)

Ah yes, you need to disallow brackets from the match, like this: {{{[^{}]*?NAME[^{}]*?}}}. You can play around with disallowing different characters to suit your situation as well. And thank you. :) — Mr. Stradivarius ^{♪ talk ♪} 06:05, 8 June 2013 (UTC)

A question about notifications

I have a question about the new notification system. When I receive a notifcation saying that a certain article has been linked, who actually gets that notification? Everyone who ever edited the article? A certain number of editors with the largest number of edits to the article? Editors who expanded the article a certain amount? A certain number of recent editors? What's the criteria? Beyond My Ken (talk) 18:25, 7 June 2013 (UTC)

Hello Beyond My Ken. If you go to Preferences → Notifications and mouse-over the little question-mark icon it will tell you "Notify me when someone links to a page I created from an article page." Technical 13 (talk) 18:31, 7 June 2013 (UTC)

Ah, thank you. I somehow didn't recognize some of the articles as ones that I had created. Beyond My Ken (talk) 20:33, 7 June 2013 (UTC)

Redirects you create that someone else expands into articles also count as articles you created. – PartTimeGnome (talk | contribs) 21:37, 7 June 2013 (UTC)

Ah! That helps too!

And speaking of redirects, is there anyway to redirect notifications from my old IDs to my current one? Beyond My Ken (talk) 21:55, 7 June 2013 (UTC)

Hmm. Not that I know of, but it would be an interesting form of wikistalking if I were able to, say, see anytime User:Beyond My Ken is linked. Perhaps that's why following other usernames beside the one you're logged in to is not supported Killiondude (talk) 21:02, 8 June 2013 (UTC)

Good point. I've solved the problem by setting notifications on the old account to got to e-mail, so I'll see them that way (if there are any). Beyond My Ken (talk) 22:49, 8 June 2013 (UTC)

Image?

Why is the image in this DYK nom showing up as a picture of Charlieissocoollike?--Gilderien Chat|List of good deeds 22:08, 7 June 2013 (UTC)

I see File:ZhangZiyi Amfar.jpg with a woman in a black dress. Are you saying you see an image of the man Charlieissocoollike instead? PrimeHunter (talk) 00:43, 8 June 2013 (UTC)

Yes. However, it is squashed in from the sides and also not in the article.--Gilderien Chat|List of good deeds 16:54, 8 June 2013 (UTC)

I suspect that your browser is stubbornly ignoring the true file content and is displaying a locally-cached copy which has the same filename. Try a WP:BYPASS. --Redrose64 (talk) 19:19, 8 June 2013 (UTC)

Thank you, it is now showing the correct image.--Gilderien Chat|List of good deeds 22:55, 8 June 2013 (UTC)

Elections banner is buggy

We're bound to get complaints about the latest WMF banner "Votes are now being accepted for the Board of Trustees and Funds Dissemination Committee election. Click here to read about the candidates and vote. [ Help with translations! ]" (it's elections, not fundraising, but people will still complain) so I'll kick it off. It's buggy: the cross-in-circle icon closes it as expected; but then it then immediately takes you to meta:Wikimedia Foundation elections 2013. It's not a problem specific to en.wp, since it happens at commons: and fr: too. I'm willing to bet it's not a something to bother bugzilla with, so does anybody know where the relevant file-a-bug page is? --Redrose64 (talk) 09:17, 8 June 2013 (UTC)

Not sure about the bug-filing page, but the notice is using m:Special:CentralNotice, so some place on Meta would be a good start. Maybe m:Meta:Requests for help from a sysop or bureaucrat? — Mr. Stradivarius ^{♪ talk ♪} 09:47, 8 June 2013 (UTC)

OK, thanks; from that first link I found Elections_voting_open in which was m:Special:CentralNoticeBanners/edit/Election2013 voting starts and looking at the logs I saw who last modified it, so I posted to their talk page. --Redrose64 (talk) 10:27, 8 June 2013 (UTC)

Thanks Redrose, I'm looking into this. It may be that the 'box' around that circle isn't big enough and so it thinks you're clicking both the circle and the link at the same time. Jalexander--WMF 22:03, 8 June 2013 (UTC)

That should be better now, I expanded the invisible 'box' that is the close link and tested on a couple browsers. If anyone has other issues let me know. Jalexander--WMF 22:29, 8 June 2013 (UTC)

Hidden audio file links

Can someone take a look at Template talk:Infobox IPA#Hiding the linkage. I'm worried that templates are once again managing to hide links to info about audio files.

The importance of additional linkage for audio file templates has been discussed several times before.

"Clean" audio templates with nothing but a play button and no other links shouldn't even be contemplated since they violate our own conditions concerning licensing and information about the creators.

Peter ^Isotalo 15:59, 8 June 2013 (UTC)

Concerns with Flow

Okay, so I've been following the discussion on Flow. There are many things that I am concerned about as it will completely change the way that talks and discussions and what not will have to be handled... The most recent thread of concern is mw:Thread:Talk:Flow/Avatars/reply (25) where it seems that not only will customizable signatures be a thing of the past, but using templates in discussion (even the simple useful ones like {{Done}} and {{Not Done}}) will not be allowed anymore either. Just plain text and a system default signature. It makes me feel like we are all truly being assimilated. Technical 13 (talk) 22:42, 1 June 2013 (UTC)

 Dislike times three or four dozen. Change for change's sake. Do they care about us oldies at all? (What will happen to all those templates already on talk pages when Flow is rolled out?) Ignatzmice•talk 22:53, 1 June 2013 (UTC)

The biggest concern here might actually be the loss of {{Help me}} and {{Admin help}} making it even harder for new users to get help... Where are those two templates suppose to go? On user talk pages... Where is Flow going to be rolled out to start? On user talk pages... *sigh* Technical 13 (talk) 22:57, 1 June 2013 (UTC)

How will we discuss the appearance of templates? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:58, 1 June 2013 (UTC)

We won't be able to use any of the {{Tl|...}} family anymore... That being said, curly brackets should just display as curly brackets from my understanding so we can just type them out (and use square brackets to link the template if we want)... At least that is my guess... Technical 13 (talk) 23:05, 1 June 2013 (UTC)

Can't even do that, apparently... Ignatzmice•talk 23:09, 1 June 2013 (UTC)

I also felt that this part of the discussion was very enlightening. It basically says, that the WMF development team made some decisions regarding Flow already knowing it will upset the community, but doesn't care because it thinks those changes are "better for the future of Wikipedia". Everything should simplify the experience for new users, regardless of usability or accustomed ways of doing things, that were accomplished long ago and work perfectly well. --Patrick87 (talk) 23:35, 1 June 2013 (UTC)

I think "Flow" (see m:Euphemisms) has the potential to be good. However, as I've stated before, the Foundation appears to be doing a lot of work to reshape Wikipedia into something... different. Killiondude (talk) 23:55, 1 June 2013 (UTC)

(edit conflict) Apparently, Flow will make it impossible to use templates to warn users. This is getting ridiculous.--Gilderien Chat|List of good deeds 23:58, 1 June 2013 (UTC)

Not to mention WikiProject Banners, the Edit protected template, Article history and a wide variety of others. Like I said in the discussion on Mediawiki. If Flow can't use templates, they may as well stop developing it and move the resources somewhere else. Too much of our system relies on the use of templates, so if they have eliminated the use of templates on talk pages, they just broke Wikipedia. Kumioko (talk) 23:59, 1 June 2013 (UTC)

The noindex template is important - at least to me. If it can't be used, I hope they consider keeping talk pages from being indexed by default. Victoria (talk) 00:34, 2 June 2013 (UTC)

I agree wholeheartedly--Kumioko, you've hit the nail on the head here. Theopolisme (talk) 00:10, 2 June 2013 (UTC)

Wait. So tools like Twinkle and Huggle would stop working? Seriously? --NeilN ^{talk to me} 00:15, 2 June 2013 (UTC)

Yep, deader than a doornail. In fact a lot of work would need to be done to AWB and a lot of bots as well. Kumioko (talk) 00:17, 2 June 2013 (UTC)

Well, eventually, I think they will be "replaced" with something called workflow. But in the meantime, usertalk pages will be devoid of custom signatures, templates, and other complicated syntax. Instead of just, I don't know, hiding the syntax, they're prohibiting it.--Gilderien Chat|List of good deeds 00:19, 2 June 2013 (UTC)

From Wikipedia:Flow/FAQ#How_will_Flow_handle_spam_and_vandalism.3F: "[FIXME]" *headdesk* Theopolisme (talk) 00:27, 2 June 2013 (UTC)

Cool. So we get a lot of newbies, using the "easier" system to proclaim "I waz here!", while editors who already volunteer their time throw up their hands in frustration and wonder why the Foundation is obsessed with rolling out "Facebook UI" widgets at all costs. --NeilN ^{talk to me} 00:28, 2 June 2013 (UTC)

• As usual, when people who are not active wikimedians design features, they have no clue what is actually required. If this design decision stays in, it obviously cannot be deployed anywhere on Wikimedia, so it would be nice if the WMF would employ their resources to do something actually useful. Snowolf ^{How can I help?} 00:12, 2 June 2013 (UTC)

Well, it will be deployed on every user talk page. That's already a fixed plan by WMF at this point in time... --Patrick87 (talk) 00:17, 2 June 2013 (UTC)

If they deploy something (Flow or anything else) that affects the flow of talk pages, they need to do it to all talk pages. Not just users. Otherwise we would now need to learn 2 separate systems for discussions. One for one group of pages and 1 or more for others. That would be about the dumbest way to "Make discussions easier" that I have ever heard. Kumioko (talk) 00:21, 2 June 2013 (UTC)

Talk about "editor retention"...seems like now everything's just about getting the new ones. It's all or nothing for the WMF... :/ Theopolisme (talk) 00:20, 2 June 2013 (UTC)

The WMF has made it clear time and time again that editor retention is not a concern of them. Their only concern is to attract new editors, especially ones who seem to be more interested in facebook and shiny graphics than building an encyclopedia. I don't know why you're surprised, it's hardly news. Replying to Patrick, yes, I know it will be deployed regardless of whether it is or isn't fit for purpose. No news there either.Snowolf ^{How can I help?} 00:23, 2 June 2013 (UTC)

Surprised? No. But I feel like if I say it enough times, maybe someone will listen. Then again, what's he going to do... Theopolisme (talk) 00:25, 2 June 2013 (UTC)

Well, if the community revolted, with Jimbo, 3 community seats and 2 chapter seat, we would have a majority on the WMF board ... --Gilderien Chat|List of good deeds 00:30, 2 June 2013 (UTC)

(edit conflict) I wonder how MediaWiki changes are implemented on enwiki, and if there's a way to pause/stop/revert them... Ignatzmice•talk 00:26, 2 June 2013 (UTC)

We'd have to fork it or something. Which now doesn't seem like too crappy an idea...well, okay, it's a terrible idea, and we'd lose most of our editors, but it could keep running on MediaWiki 1.20.6 ad inifinitum. ;) Theopolisme (talk) 00:30, 2 June 2013 (UTC)

Well a lot of people have been trying to get rid of me. Implementing Flow just might do it. Kumioko (talk) 00:28, 2 June 2013 (UTC)

Admins can change the interface pretty freely; when Wikia implemented their new skin a load of administrators managed to remove it .... of course, they were all desysopped when they tried to fork.--Gilderien Chat|List of good deeds 00:34, 2 June 2013 (UTC)

That's just a skin, though. Not the underpinnings of MediaWiki itself. Ignatzmice•talk 00:35, 2 June 2013 (UTC)

Flow is a mediawiki extension, which means it is installed on the server-side. So we'd need a rogue WMF employee or something. Theopolisme (talk) 00:37, 2 June 2013 (UTC)

There would be a way round it. But (and I would probably do this) this would increase the divide between new and established editors even further.--Gilderien Chat|List of good deeds 00:39, 2 June 2013 (UTC)

If it came to that, I honestly would advocate a fork. Theopolisme (talk) 00:43, 2 June 2013 (UTC)

I can't remember where I read it, but I thought something said that Wikipedia was successful in its early days for being simple and not trying to use advanced and complicated technology. Things like Flow and Visual Editor seem to be complicated ways to reinvent the wheel, but only a partial implementation of what we currently have (like all wheels are now semicircles). As an example, this FAQ about Flow says that "A singular package will not and cannot cover these cases. So we have to build our own." But there is a singular package: the thing we currently have.
Also, it is important to gain new users, but alienating the existing editor base is suicide. Retention is as important as attracting newbies. Also, if someone can't overcome the minor barriers that may or may not exist in the current interface, are they someone capable of crafting this encyclopedia? Also, from what I see, these new "features" make some things easier but erect artificial barriers preventing many others.Chris857 (talk) 00:47, 2 June 2013 (UTC)

• I'm glad I Like to because I seem to have opened up a can of worms... I would love to see some WMF response here... Perhaps we are all "just missing something", but I fear we are not... I'm starting to  Dislike Flow more and more, and it hasn't even been written yet... Technical 13 (talk) 00:49, 2 June 2013 (UTC)

Maybe you should try out the interactive prototype? :) --Gilderien Chat|List of good deeds 00:53, 2 June 2013 (UTC)

I was already going to avoid Flow at all costs. That some users, including myself, "will not be able to edit or add comments" is what ruined it for me. From the above, it seems many others will also be avoiding it, and for good reason.

The WMF is determined to push through changes unfit for purpose regardless of what we say, so we must consider how to workaround such changes when they arrive. Once Flow is required for talk pages, I thought to move my talk page to User:PartTimeGnome/Talk to take it out of talkspace. The scratchspace idea mentioned above is also good. Unfortunately, both ideas would mean losing talk page notifications, though I could ask users to mention me each time they post.

I hope it goes without saying that resisting the organisation controlling the servers is a bad position to be in. Since we can't work with the changes the WMF is forcing through, the WMF needs to change. There is an opportunity for this very soon: the Wikimedia Foundation elections start on 8 June (next week). Use your vote wisely! – PartTimeGnome (talk | contribs) 02:15, 2 June 2013 (UTC)

Amen. Here is what I think: If Flow is going to cause this much trouble, it is not worth whatever improvements it may bring. AutomaticStrikeout  ?  02:52, 2 June 2013 (UTC)

Before this discussion goes any further, I just want to point out that a lot of what is being said about Flow is nothing but rumour or misinterpretation. It seems that the WMF is asking for community feedback before they develop the tool (as opposed to what happened with, say, AFT), which is something we as a community should welcome. But just grumbling about the supposed "features" of the tool here isn't a very productive use of time. If you are concerned that Flow will not allow the use of templates in discussions, then go and have a friendly chat to the developers, see what their side of the story is, and then explain how you disagree with them. Simple as that. — This, that and the other (talk) 03:48, 2 June 2013 (UTC)

I may be reading this wrong, but from the discussions linked above it seems Technical already had that conversation, and Jorm said "Nuh-uh." But if they do decide to change that, wonderful. And I might be wrong. Ignatzmice•talk 04:00, 2 June 2013 (UTC)

• Let's be clear here; we're at the discussion stage. The team actively working on Flow consists of Brandon, who is actively talking through things. Now: yes, we may lose templates. The intention is not to lose anything by losing templates. What I mean by that is that, largely, templates aren't the end-goal, they're the method; the goal is being able to signify that a user needs help, or is blocked, or...etc, etc. These are things that can be implemented in other ways. Nobody at the WMF end wants to lose the underlying functionality that makes templates useful. Okeyes (WMF) (talk) 04:05, 2 June 2013 (UTC)

I'm in the process of writing a response. Today is a non-work day for Foundation folk; I was down in Santa Cruz.--Jorm (WMF) (talk) 04:06, 2 June 2013 (UTC)

• • @Okeyes So are you saying Flow will not be implemented before acceptable alternatives for Twinkle, Huggle, Cluebot, etc are rolled out? --NeilN ^{talk to me} 04:09, 2 June 2013 (UTC)

Don't panic. Right now, Brandon (Jorm) is actively floating ideas on how Flow could work, including potential alternatives to existing workflows. Nothing has been implemented or set in stone yet, and now is a good time for ideas to be tested, kicked around, prototyped and, in some cases, shot down. The whole point of having this discussion early (with only an interactive prototype in existence) is so that issues can be surfaced early in the development. That's a good thing. Give Brandon a chance to respond in a bit more detail, and then we can see if we can come up with an approach that addresses key concerns.--Eloquence* 04:46, 2 June 2013 (UTC)

Response from Jorm

Well, hasn't this been fun! I'm just going to comment on everything here, in a subsection, because REASONS.

Here's your bullet points:

• Yes, you can still warn users.
• Yes, we've made implementation decisions already, based on back-end constraints.
• Yes, bots, twinkle, huggle, awb will continue to work. Anyone who says otherwise has been Caught Not Reading.
• Yes, you'll still be able to add templates to page boards (though we're not going into Article talk pages yet). There will be a "non-structured" area on every page. Existing templates will likely migrate but again: that's not where we're at right now.
• Yes, we're thinking seriously about restricting the ability of allowing anyone to edit other people's comments willy-nilly. This is a complicated topic and we're thinking through several options.

Okay. To the meat.

I wish this discussion would actually have taken place in the multiple places provided for it, and I wish that it had been started on a work day, and I wish that it hadn't had several hours to cook and cycle upon itself without a response from me because it's a Saturday and I was at a cook out with my in-laws. I also wish that there were more assumptions of good faith and trust.

In fact, I think I'm gonna talk about that for a second. Friday was the third year anniversary of my employment at the Foundation. That's a really long time in Silicon Valley years and it's more than enough time, I think, that we should drop the whole schtick about "Foundation designers don't know the community" and "they're trying to turn it into Facebook" and "you don't listen to us" and all the other jazz. I think you'd be disturbed at how well we understand the processes used by the various wikis and I think you might be saddened if you understood how hamstrung we are in making your life better because the complexity of the process is hypnotic. Ask people whether or not Special:NewPagesFeed isn't an improvement and then ask me how many hours were spent studying how page patrollers work and interviewing patrollers and basically absorbing everything about it. Was the final product exactly what any one patroller wanted? Probably not, but it was closer to what they needed.

If you think - even for a moment - that there are not people who are thinking about and discussing every one of the problems or issues that have been brought up above, you're wrong. And if you think that we're working in Bad Faith, there's nothing I or any of us can do for you.

The only thing I can ask you for is your input. I think we've been pretty damned good about trying to communicate and ask for input.

Okay.

Let's start with templates, which I think is what everyone is really freaking out about when it's boiled down.

First, no one has said, ever, "well, we're doing this, and screw you and your processes, you're just out of luck." In fact, we've been pretty solid about saying "we're going to help you in any way you can". In fact, "buried" in the global navigation on every Flow portal is a page describing a "Workflow Description Language". We're planning to give you something to replace your templated workflows and make them better and easier.

Second, no one has said, "well, bots and Twinkle and Huggle and AWB people are screwed." No, they aren't, and I'm frankly finding it hard to jump to that conclusion. How will Twinkle work? Simple: we grab the hook off "create section," take the template that it wants to drop, parse it into html, make sure the Parsoid understands it, and create a new Flow Topic with the html as the post text. That's it! And even better: the conversation is now managed.

• Ah, but what if - what if - what if we could make warning a user a real, true workflow? What if, instead of a spray-and-pray template, we can initiate a workflow that actually tracks how many warnings a user has, makes sure the user has seen and acknowledged them, and then also provides them with interactive tools to learn about what they did wrong? Wouldn't that be neat?

Let's now tackle the "devs are making decisions without us" line of thought.

Spoiler: Of course we are. Absolutely we are. You, as a community, cannot individually be expected to understand how our software back end works. Nor can you be expected to understand how to program. Or have studied human interface design, or even know anything about computers at all. I'm not saying that some of you don't: I know many members of the community do.

I am saying that it is our job to know about all of those things. What this means is that we sit and look at our design constraints and look at what our goals are and how the system (e.g., community processes) works, and how the system will be impacted, and so forth. We read tea leaves and we think about The Future - not just as it relates to enwiki, but to all wikis.

Here's the future and I don't think it's a surprise to anyone: The VisualEditor.

That adds a massive constraint to whatever design we come up with. Whatever content gets entered into Flow must be readable, parsable, and editable within the VisualEditor. It is simply a non-starter otherwise.

Currently, the VisualEditor (and Parsoid, which is our real constraint) does not handle templates very well - at least not well enough that we can (at this time) state for a fact that all templates can be parsed by it. The fine developers working the VE are hustling to get these things working but the timeline isn't "next week". Ergo, we can't depend on it, so we have to treat it as a design constraint.

That brings me to the next constraint: scalability and the Parsoid. I walked through the issues with this before and it's a lot of text so I won't repeat it here. The gist is "running every post through the parser on load is not scalable". It's just not possible to do.

We're also not going to be storing the data for Flow posts in the local wikis. The database structure doesn't allow for it (they're built for horizontal scale, not vertical, and Flow requires vertical scaling). That means all Flow posts get saved to a different database system (another constraint).

(There's an interesting side-effect to that, but I'll leave it as an exercise to the reader to figure it out. For now.)

Let's walk back from the ledge, people. This is all good stuff. I'm not going to lie to you: it's going to be change, and it's going to hurt for a bit, but we'll all get through it.

It might be a fun exercise to sit and think about how many things we can fix with Flow, rather than how many things are going to change.

This was long. It's Saturday night. I'm going to spend what remains of it with my wife. I'll try to be available to answer questions tomorrow (Sunday). I'd prefer it if these questions were left at mw:Flow Portal, so they're centralized, but I'll talk here as well.--Jorm (WMF) (talk) 04:52, 2 June 2013 (UTC)

Thanks for the detailed explanation Jorm. I understand this discussion may have seemed somewhat premature and bad faith but given the recent changes that have been coming out that were, arguably, not helpful, I hope you can understand our concern and reluctance at the potential that this would eliminate the ability of using templates.

Enjoy the rest of your weekend. I have been married a couple times, you have to do the same thing to keep them as you did to get them, it took me a while to figure that out. :-)Kumioko (talk) 05:02, 2 June 2013 (UTC)

Jorm, my thanks as well. Enjoy your night-- Theopolisme (talk) 05:10, 2 June 2013 (UTC)

Thank you for your response. May I suggest putting some of it in here? --NeilN ^{talk to me} 05:56, 2 June 2013 (UTC)

About the exercise to the reader: should we take it as a hint that 'local wikis' is plural while 'different database system' is singular? — HHHIPPO 10:19, 2 June 2013 (UTC)

Thank you for your response, just one thing though - "Anyone who says otherwise has been Caught Not Reading." ... I have read as much as I can find and I haven't found this said anywhere; Huggle especially relies entirely on templates so presumably it would have to be re-written.--Gilderien Chat|List of good deeds 11:05, 2 June 2013 (UTC)

WP:FLOW was created too early since the pages describing Flow have insufficient explanation of how common talk page actions would occur. Of course there can be no detail at this stage, but there should be a 20,000 foot overview of fundamental issues like whether Flow will handle standard warnings, and how abusive posts (or spam or trolling) can be removed (hint: asking an admin is not acceptable). The other issues mentioned at WT:Flow should also be addressed. Johnuniq (talk) 11:26, 2 June 2013 (UTC)

• Jorm (WMF), thank you for you taking the time to respond here. Being the one that has opened this discussion here (and a discussion elsewhere questioning the Borgification of signatures (which I'm not saying is entirely bad)), I want you guys to know that I really am assuming good faith on your (the Foundation's) part (I've even gone out of my way to try and stick up for you in some of these threads like here). I'm far from opposed to change. As you know, I've been following this discussion on the MediaWiki liquid threads and I've been following as much of it as I can find on Bugzilla (I'm on the mailing lists as well), and trying to ask important questions and understand it in both places and addressing concerns. I just wanted to make sure that everyone was aware of some of these things and had a chance to offer some more input to the process. No, I'm not saying they don't have the same ability as myself or anyone else to go to MediaWiki and follow all of it like I have, simply that some may not have the kind of time required to read all of the messages if follow it at all or are simply unaware that it exists there. The template thing is a huge concern of mine (and apparently others) because there are so many tools that rely on them from Twinkle, Huggle, Snuggle, AWB (less so because it isn't as often used on talk pages) and critical processes such as warnings, help/edit requests, teahouse invitations, wikiproject banners, afc/dyk/fa/deletion/block notifications, etc... I would love to help in anyway I can to create alternatives or make these functional within Flow before Flow is rolled out... So, do you think that WMF and the community can work together on this instead of the foundation just saying "hey, we researched everything and we know how your systems work better than you do and this is what we devised based on that..."? Technical 13 (talk) 12:12, 2 June 2013 (UTC)

@Jorm I think there are a lot of flaws with your statements above and with your assumptions in the article about the Athena project linked below. I do think your intentions are pure so I don't want anyone saying I am not assuming good faith but here are a few of my concern which I had last night but saved posting them to let you enjoy your night:

1. First, not posting on a weekend because you don't work on weekends shows a huge lack of understanding about the dynamic and global nature of how the community works. Or a lock of caring. Either way its not a great thing. The community edits 24 hours a day 7 days a week. We should not need to save our comments and concerns for a WMF work day because the primary developer doesn't edit here off work hours.
2. Next the comments about posting at the MW site is pretty much silly and again shows a fundamental lack of understanding about how the community works. The vast majority of the community never edits there and wouldn't even know the discussion was there until it was too late. Even on this page there is a limited number of people who comment and most of those are admins and technical folks. If you want to ensure that few comments are made and make the point later that no one commented so everything must be fine, then hiding the discussions in MediaWiki is a good way to do just that.
3. The technical aspect of the site is much more of a minor problem than the uncivil and toxic nature of how newby's are treated. I agree its a little dated and it could stand some updating but we aren't Facebook and the people who edit here are doing so for different reasons than Facebook or social media so using the mentality that Facebook spent a lot of time and money developing it so it must be good for us as well is fundamentally flawed.
4. The vast majority don't leave because they have trouble learning how to edit. They leave because the community treats them like crap if they aren't born with the knowledge of our rules and some block happy admin blocks them the first time they don't sign their posts or some other stupid thing. If you want to keep editors, work on culture toxicity, not on implementing a secondary talk page discussion system so they have to learn 2 and eliminate make it so we cannot use templates.
5. Another big reason we are losing editors is that they aren't leaving, we are diluting our pool of editors with new projects as the come online. With every new project we add (Wikidata, Wikivoyage, Wiktionary, etc.) we lose some editors to this new project. I don't want to sound like these projects are a bad thing because they aren't and that's not what I mean to imply. But it does spread us thinner so our resources don't go as far as far as human capital goes.
6. You state that no one has said "well, we're doing this, and screw you and your processes, you're just out of luck." Really, isn't that almost exactly what they have said in multiple occasions in the past, including the elimination of the Orange Bar of Doom? Because I distinctly remember at least 2 comments from WMF folks implying exactly that.
7. You also stated "well, bots and Twinkle and Huggle and AWB people are screwed.". Of course there will be a way to work around the problem but these things will need to have some modifications made to them if this goes through. That modification might need to include just not updating whatever page Flow is displayed on. So although you are correct that no one said they/we are screwed, no one made it clear in any instructions before now that these would not be affected. Additionally, although several of these applications were designed by or supported by people who work at the WMF, none of these applications are actively "supported" by the WMF. So I could easily see the attitude of well we don't support it so its not our problem if it breaks. And it wouldn't be the first time the WMF had this attitude by the way.
8. There are a lot of improvements that Visual editor will bring I agree but it still has a ways to go. Even when it is released, its likely that we will still need an advanced editor in the form of what we have as the current edit capability.

In summary I'm glad you took the time to post and I very much appreciate that as well as other community members do. But the general tone of your post is that of a general lack of empathy and frankly indicates exactly the problem with the "well, we're doing this, and screw you and your processes, you're just out of luck." comment you made above. Kumioko (talk) 13:58, 2 June 2013 (UTC)

Wow. That's...certainly something. Let me go through, but by bit.

1. I don't think it demonstrates a lack of understanding about the community; do you think after three years of heavily engaging with the community, Brandon was ignorant of the fact that we're a global, volunteer-based movement, and that editors can post at any time, from any place? As someone who has worked with him very closely for 2 of those 3 years, Brandon gets it to a degree most staffers don't - to a degree that some community-sourced staffers don't. He wasn't saying he was ignorant of this community trope; he was saying that, weirdly, staffers sometimes need to take time off. As someone who has done the whole work-90-hours-a-week-every-week-for-a-year schtick, I've started trying to take weekends for myself, too (as this demonstrates, I'm not very good at it). I don't think people get the long hours that staffers work, here. It's not Brandon not understanding the community, it's Brandon understanding that working 120 hour weeks would drive him insane. I have absolutely no desire to wander into the office and find him, mind broken, wandering pantsless around the 6th floor chainsmoking Marlboro Lights and singing 'I Will Survive' over and over again. I doubt anyone else wants that mental image either. If you truly think staffers should be active whenever editors are active then you're asking for the WMF to be run by ELIZA, because that's the only way we can keep up.
2. Nobody has told you to post on MW.org. Please point me to the bit of Brandon's post where he mentioned MW.org as a venue. We are not ignorant of the difficulties around it; if you look at the engagement strategy I wrote for Page Curation, a project Brandon worked heavily on, you'll see it specifically called out as a problem. What Brandon meant is that there are several other perfectly good venues for this kind of discussion, one of which is right here on enwiki.
3. Citation needed for your third statement? I'll agree that a big chunk of people who register in the data as 'editors who leave' leave because of community toxicity. This is nothing to do with the relative difficulty of overcoming toxicity versus overcoming technology, it's to do with poor science; by definition, everyone who edits and then leaves can handle editing. When we look at surveys of ex-contributors or that sort of data, or just anecdotes, of course we're going to be biased towards people who grok markup and leave for other reasons. People who don't grok markup can't participate in the observations.
4. No comment on diluting the pool, really, except to say that we're talking about Wikimedia-wide data on editor decline, not enwiki-specific data. We're not losing them, as you note.
5. We're not talking about the orange bar of death, or any of the other occasions. We're talking about Flow, let's be clear. You may as well tar the development process with the IEP brush, if the approach that you're taking is one where prior actions are complete predictors of future actions taken by a different set of people.
6. Sure, they'll need some modifications. We know this; I spent about 40 hours writing up use cases for everything we'd need to support in the existing talkpages - not just twinkle or huggle, but the underlying mechanisms, like having a good external API for Flow and making sure that we reach out to the volunteer developer community and provide clear instructions and help with such things.

In summary, I don't see Brandon's post as indicating a lack of empathy; honestly, if he didn't appreciate the feelings the community had do you think we'd be having this conversation, let alone making plans to ensure things like Twinkle support work? If he didn't care - if we didn't care - here's what would happen. We'd keep all the documentation on MediaWiki.org, we'd have built the software already around our utopian community workflows, we would've silently deployed it, and, absent bugzilla reports, not given a brass farthing what anyone said. That's quite clearly not what we've done. I'm sat here at 6pm on a Sunday evening writing out a ludicrously long counter-counter-argument to follow your counter-argument to another staffer's argument because We want to keep people informed about and involved in the process. And that counter-argument I'm responding to is, depressingly, one that alternately argues our culture is toxic and states basically that "well you should be contributing whenever an editor contributes, then. Any alternative just means you don't care about us". I'm disappointed by the cognitive dissonance I'm seeing here.

As I've offered before, Kumioko (and I hope you'll take the offer up, this time); if you want to discuss the factors at play here, or Flow generally, I'm certainly willing to free up an hour for a skype call or a google hangout. The same goes for any other editor who wants to talk through...well, whatever they want, really. Okeyes (WMF) (talk) 16:53, 2 June 2013 (UTC)

• KumiokoCleanStart, I think that while most of your statements are how you personally feel towards the WMF team and may be written based upon good intent, they are mostly unfounded and most of them are completely unfair in my opinion. There really is a big gap in the communications between them and us, and I agree that needs to be addressed. I view a large part of your comment as flaming and bashing of the WMF team and I commend them for their efforts to bite their tongues as well as they have been. Finally, I would really appreciate it if you would do something about your username, I find it disruptive and counter productive... I am barely aware of whatever you had to go through before, but that being said, having the username of "KumiokoCleanStart" and not actually changing your ways implies to me that you really do not wish to have a clean start. Anyways... That is between you and the admins, I just wish you would stop being so disruptive and every comment being to complain or mock or flame someone else. I implore you to look in the mirror and ask yourself how you can improve yourself. Now, since I expect something of a "With all due respect Technical 13" response from you for this comment, I would like to make sure that you know ahead of time, it would be a waste of time... Technical 13 (talk) 17:45, 2 June 2013 (UTC)

• Actually I have met Brandon (although I'm certain he couldn't pick me out in a crowd) and quite a few of the other folks at the WMF and harbor no hard feelings or ill will towards any of them. I found most of them to be very collegial and personable. I also think that some of my statements above are being taken out of context which doesn't really surprise me much either. Clearly I must be the only one who has issue with the comments from Brandon above. I have no doubt that he and the WMF folks mean well but frankly, given the changes that have occurred lately, I wanted to make sure my comments were out there. If they choose to listen and consider my comments or ignore them or if you and others think I am a nut, that's fine. Just remember this discussion a few months from now when Flow comes out because I have enough experience in the IT field as a project manager to see the writing on the wall. So since the comments seem to indicate my input is not wanted or needed I am going to move on and go back to editing. Let them release Flow, break all the templates and cause problems for the admins. Not my problem anymore. I have voiced my concerns and said my piece. There is nothing more I can do since its clear that nothing I say is going to be taken seriously anyway, I'm just wasting my time. Which is IMO not a unique issue with me and a byproduct of the culture here in the project. I'm not an admin nor a member of the WMF so as just an editor, and not a particularly popular one at that, my opinions are of little interest or impact. The reason I keep bringing up the bit about the culture is, strangely, I don't see anything being done about it. Lots of talk about Facebook like pages and making it easier to edit, but the only comments about the culture are directed at me and how your tired of me bringing it up. If your tired of hearing it, then do something about it rather than kick the can down the road. I analyze things, that's what I do and I often offer suggestions to fix it. But I can't make the changes. Hell I can't do a lot of things around here to help out that I would if I could. Because we are more worried about keeping the power in the hands of a few, than enabling editors to edit and buildup the site. That is the problem with our culture. We are driving the editors off with our actions. Not because they can't figure out editing. If you want to retain editors. Look at fixing those issues first. Otherwise your just putting makeup on a pig! No matter how pretty and easy you make the site, if people are still being shitty to one another, they ain't gonna stay because it looks like Facebook.
• As for my username this is hardly the place but since you brought it up I'll explain it again. I tried to create a new one and was blocked for socking from an overzealous admin. Then I edited as an IP and once again I had editors crying that I was socking. So I recreated this username and yes I am poking some fun at a lousy policy (clean start) because it doesn't work. Our other policies and culture prevent if from working. If you have to link your old account name to your new one its not a clean start. Frankly if I knew what I now know that I wouldn't be allowed to edit as an IP or create a new name I would have kept the old one with the vast majority of my edits and edit history. But its too late to change it back so now were all stuck with this one. Happy editing and there's no bother replaying to my comments. I'm not going to get involved in the discussion anymore. You all can talk about how wonderful Flow is going to be without my interventions. Kumioko (talk) 22:33, 2 June 2013 (UTC)

• Kumioko, nobody said we didn't want to hear your issues. We said we didn't want to hear complaints about how Brandon doesn't care because he doesn't work 24 hours a day, 7 days a week. There are some very good reasons why the WMF does not get involved in cultural change, and again, for the third time, I am happy to talk to you in more detail about this issue and/or any other. I hope that this time you might either take me up on my offer or at least offer a response. Okeyes (WMF) (talk) 23:20, 2 June 2013 (UTC)

Okeyes, No one expects Brandon or anyone else to work 24/7/365 and that is not what I meant. What I was referring to was Brandons comment at the start of his post'I wish this discussion would actually have taken place in the multiple places provided for it, and I wish that it had been started on a work day, and I wish that it hadn't had several hours to cook and cycle upon itself without a response from me because it's a Saturday and I was at a cook out with my in-laws. I also wish that there were more assumptions of good faith and trust.'

As I said above, few of us watch the other places so there should be little surprise that no one is commenting there. There is no reason for this to Start or happen on a WMF work day, disussions often cook here and fester and boil. If the WMF is not keeping the members of the community in the loop, things will get blown out of proportion because the WMF isn't relaying that information. If you write a 3 sentance description about Flow and in it say things like Signatures and templates won't work with no explanation of why or how that will be worked around, don't get mad at me or others because we call you out on it. This is an opportunity for growth and development for all of us. We can take everything offensively or take the comments in these discussions as an opportunity for improvement. Lastly certainly I think everyone understands that Brandon and anyone else should get to spend time with their family. No one and certainly not me would have though the less of him if he would have left a comment saying I will comment in detail on Monday I am spending time with the family. I'm glad he left the detailed comment and I am sure he was frustrated at the situation as are we all. But many of his comments raised more conerns and I commnted on them. I got to where I am in my real life because I don't suger coat things and I don't generally hide behind politics. If I see something wrong I work to address fixing it. I am not shy, timid or calculating. I am blunt and often times in text only environments it comes off as abbrasive. Its not meant to be. It doesn't change the problem though. Flow, as advertised, is not an improvement for us here. It could be if the issues are addressed. But not in its current state. Kumioko (talk) 15:17, 3 June 2013 (UTC)

Per Kumiko's comment a long way above, the VisualEditor can never completely replace the source editor. The VisualEditor is good for convenience and for the less technical among us. However, there are various tasks that would be impossible with a WYSIWYG editor (editing parser functions, CSS, JS, Lua scripts, ...), and other tasks might be harder using WYSIWYG. Furthermore, the VisualEditor cannot work without JavaScript; the source editor provides a fallback for editors unable or unwilling to run scripts. Please do not consider the VisualEditor as the future; the future should be VisualEditor and the source editor. – PartTimeGnome (talk | contribs) 23:24, 2 June 2013 (UTC)

The VisualEditor always has had a source editor component planned; we're not going to be removing that for just those reasons. Okeyes (WMF) (talk) 23:31, 2 June 2013 (UTC)

That's basically the opposite of what Brandon told me before. According to him (at least regarding Flow) Wikitext will be abandoned completely and everything will be designed to work properly with VisualEditor. A source editor will only be made available for people without JavaScript enabled and will only offer a very limited set of function (even more limited than the VisualEditor. Can you explain this discrepancy in your statements? --Patrick87 (talk) 00:08, 3 June 2013 (UTC)

That's not the opposite of what I said. "Source Editor for articles" is not the same as "source editor for discussions". You don't need to edit CSS or Lua scripts to respond to someone in a thread. Ergo, it's not going to be there.--Jorm (WMF) (talk) 00:29, 3 June 2013 (UTC)

It is impossible to implement the VisualEditor without JavaScript. Therefore the source editor is needed as a fallback for non-JS users. Participating in discussions is core functionality, so it must function without JavaScript. There's nothing wrong with non-JS users having a degraded experience (i.e. no WYSIWYG editing), but they must be able to post in discussions somehow. (Also, because you don't understand the need for something is not an argument to remove it, unless it causes some other problem. Things should be easier for both developers and users if the editor behaviour is broadly similar regardless of where it is used. It should mean fewer code paths to test, and less user confusion due to differences in the available functions.) – PartTimeGnome (talk | contribs) 01:02, 3 June 2013 (UTC)

OK, I see. So basically the idea is to have all (?) functionality of the current WikiEditor in a future VisualEditor source editing component, but deactivate these functionalities selectively at places where they are not needed? So in the "unstructured" board section everything (?) that is currently possible will be possible in Flow, too, but in comments on the threads only basic text formatting will be offered? --Patrick87 (talk) 01:05, 3 June 2013 (UTC)

P.S. I've used CSS in talk page comments a few times. I often participate in technical discussions about CSS, and it is useful to be able to show how a given piece of styling will appear. Your assumption that CSS is not used in discussions is incorrect. – PartTimeGnome (talk | contribs) 01:41, 3 June 2013 (UTC)

• I am satisfied with your response, Jorm. It was thoughtful and now that you have given it these concerns I have are fully addressed. Unrelated to the stated problem, it seems that both WMF developers and the WM community are dissatisfied with the communication channels between each other. The existing communication resources - for whatever reason - are not meeting my needs, and other people may feel the same way that I do. This problem may or may not be able to be solved, but if it is not solved then I would expect it to continue. Blue Rasberry (talk) 14:29, 2 June 2013 (UTC)

I've been thinking about this recently, so this is addressed to the problem you raise (not to you directly) ...

There are 2 aspects to the communication channels problems: Quantity, and Location. (This goes for any example, from ARB/ANI decisions, or MoS changes, to site-code changes.)

• Quantity of items: Some people want to know about all the hundreds of plans/changes/decisions. Most people only want to know "What's going to effect me?"
• Quantity per item: Some people want ALL the details, and will be upset if core aspects aren't mentioned. Some people just want a brief synopsis in clear non-technical English. Some people want terse bullet-point summaries.
• Location: There are a large number of locations that people expect/want/wish their news to be browsable. Some people want it all in one spot and only one spot. Some people want each communication placed in a topic-appropriate location and then mentioned in numerous other places (often leading to fragmented conversations at each external "pointer" eg this one which started as a pointer to Mediawiki). Some people want mass-duplication of anything relevant, pasted to everywhere potentially relevant (eg the 3 Flow portals at mediawiki/meta/here).

Add to which: Some people are reluctant to leave their "home" wiki, for a variety of reasons.

On En.Wp alone, we have all of these: WP:Dashboard and Template:Noticeboard links (compendiums), WP:Wikipedia Signpost, WP:CBB, Site notices, watchlist notices, WP:Update, etc

Then the meta/foundation/mediawiki wikis, and their various structured locations for centralized or separated discussion. Plus all the other languages, and all the sister projects in each language.

Plus all the official blogs, unofficial/personal blogs, IRC, and the voluminous mailing lists.

E.g. If we added all the discussions from http://lists.wikimedia.org/pipermail/wikitech-l/ into this WP:VPT, it would be overwhelming. But that's essentially what some people want (I.e. A say in every matter, and every matter brought to their home-wiki, and every matter discussed in the place they feel is most appropriate).

Back to Flow: Based on mw:Flow Portal/Use cases, and a few other pages I've glanced through: the 1 person working on this, and the people assisting/advising/discussing it with him (i.e. Us, and all other wikimedians), might be aiming to partially improve this flawed situation, with Flow itself (as well as dozens of other primary goals). The only way we'll know if it's an improvement, is if something gets built, and tested. So we have 3 options: (1) Provide feedback/bugreports/code/suggestions to improve whatever Flow turns into, or (2) Invent our own superior solution (and build and test it), or (3) [insert negativity] as some did at the start of this thread.

Helping to build stuff is why we're here, so options 1 and 2 are the only ways forward. –Quiddity (talk) 03:14, 3 June 2013 (UTC)

• General comment Concerning 'good faith' - I assume good faith on the part of the Jehovah's Witnesses or Mormons at my door (never at the same time, unfortunately - could be fun, that...). That doesn't mean that I agree with them in the slightest, or have any desire at all to convert to their faith. (I don't assume good faith on the part of the person trying to sell me a new driveway, or telling me that my roof needs urgent repairs.) Part of the trouble down here on the factory floor is that we rarely seem to see the names of the people perpetrating the changes down here in places like NPP, AfD, AfC and so on. They may have been here long ago, or we might have missed seeing them. I would repeat a comment I made somewhere in the OBOD altercations - progress is change, but change isn't always progress. I don't expect the designer of a new machine that makes veeblefetzers to spend months on the factory floor. I would hope that they know what a veeble is, how one fetzes with it, and to have some acquaintance with the working procedures and safety/comfort of the poor bugger that's going to operate the machine. All of which have more importance than do the scrolled handles, the Ionic supporting columns and the chromed dome over the hopper. Peridon (talk) 18:12, 2 June 2013 (UTC)
  • This reminds me a tad of a great story a colleague recently told me. He was hired by this company to redesign their product language model. When he arrived he was witness to a ton of old technology and already smelled trouble. He then designed a new replacement language, that handled everything the old language did, and added a ton of new functionality in the language. It also included an editor, with autocompletion, syntax highlighting and validation, preview rendering etc. His first draft was reviewed. They loved it, but then came responses like: but how are we going to find the line number of this piece of block ? He answered line number? what would you need that for ? Well, we still need it to run on our 80x40 (column x lines) based storage system (small detail, why would you ever spec that... :D ). Turns out their entire storage reference system was based on their old display and interface formats (old Vax systems). He then gave them the only logical answer; if you want to keep using your 80x40 storage system, you better keep using what you have right now, there is nothing modern that will ever map on it. The real question is, why do you want to keep such a storage format, and not invest into replacing it, so that you can use this great new language that could make your products so much more flexible and your people so much more efficient ? The engineers protested loudly about all the systems that they would need to replace and all instability it would bring. My colleague concluded: there is nothing I can do for you, not a single language I design will help you any further.
    We shouldn't have the problem you describe, but we definitely don't want the problem I just described either. The balance has to be somewhere in between. The company in question is almost bankrupt now btw. In their industry, they were like Nokia and suddenly there was the iPhone. —TheDJ (talk • contribs) 19:00, 2 June 2013 (UTC)

Hi Jorm. I'd like to clarify a few things: you mention we will be able to use templates on Flow boards, and there will be a non-structured area on each page. Am I correct in my understanding that templates will only be allowed in the non-structured area, and not in regular posts?

You also mention that Flow will still be able to use templates from things like Twinkle (albeit internally expanded into HTML). Why can't the same approach be used for comments from editors? Will the ability to use templates in a discussion only be available using the API?

The expansion of templates into HTML effectively means every template would be subst'd. If this were allowed for editor comments, the automatic substitution might confuse editors who re-edit their comments and find they don't look the same, especially if a template has expanded into something lengthy and complex. This could be solved by storing the original wikitext alongside the expanded HTML; the edit page would show the original wikitext and generate new HTML upon saving.

In many of your comments you appear to say that Flow can replace the functionality of all existing templates. Though this might be true for templates that form part of various workflows (RFCs, warnings, edit requests, etc), what about other templates? Various convenience and formatting templates are frequently used in general discussion, such as {{code}}, {{diff}}, {{small}}, {{smiley}} and {{tracked}}. There's also {{tl}}, which I heavily used in the previous sentence. Another common use of templates is demonstration, either to demonstrate the use of a template, or to give an example of a proposed edit to an article (I'm assuming templates will still be allowed in articles). How will we do these things with Flow? – PartTimeGnome (talk | contribs) 23:03, 2 June 2013 (UTC)

Templates will be allowed in the non-structured area, yes. Or, at least, that's the current thinking. And no, not in the regular posts.

I'm simplifying what will happen significantly but yes, the principle aligns with "substing" everything that goes in. The reason this works for API edits and not "website" edits is that API edits do not (currently) run through anything that the VisualEditor deals with. If the only way for website edits to happen is through the VE, then only VE-pure code happens.

Now, I'm going to be honest: it's highly likely that many templates left by Twinkle and other applications will break. But, as we've done before with other projects, we will be working with the maintainers of those tools to make sure that things are seamless and will require little or no effort from the editor community to account for the changes.

This is not our first time at this rodeo. As it were.

And yes: technically, we will probably store a "wikitext" version of the page. But that version of the page should be considered "cold storage" and not accessible in the moment to moment use of the software (for the performance issues outlined above).

And regarding the templates you described above: roughly half of those templates either are (or should be) natively supported by the VisualEditor, though in other formats (like linking to diffs, or creating font size changes, or source code). Others (smiley) could be trivially implemented with an emoji generator, and the "tracked" template is an ideal candidate for conversion to a Flow workflow.

In other news, I'd still like it if these questions were moved to WP:FLOW.--Jorm (WMF) (talk) 00:38, 3 June 2013 (UTC)

Okay, the templates I mentioned are supported by VisualEditor. Can the same be said for the hundreds of other formatting/convenience templates used on talk pages? Templates allow regular editors to define new ways to format text that other editors can easily reuse. With VisualEditor, any new formatting options would need to be added by a developer.

Also, you didn't mention how templates or proposed article edits can be demonstrated in Flow. If I wanted to say "template foo will look like bar when used with parameters baz and qux", I would typically invoke the template in place of bar. How would I say this in Flow?

I think the main problem here is this fixation on the VisualEditor. The VisualEditor is a great idea and I support it, but it can never hope to do all the things we do in wikitext, not even on talk pages. As I read it, the main reason you are saying "no templates" is because the VisualEditor does not support it. Furthermore, its dependence on JavaScript means some editors cannot use it. Relying solely on the VisualEditor introduces too many constraints. We really do need the source editor as an option. – PartTimeGnome (talk | contribs) 01:34, 3 June 2013 (UTC)

As far as people are concerned about Twinkle, please don't be. Twinkle is actively maintained and can be updated to fit any software changes. It is foolish to try to design new software features around local gadgets, of all things. And, who knows, perhaps some aspects of Twinkle will end up being built into Flow itself? — This, that and the other (talk) 01:06, 3 June 2013 (UTC)

F.L.O.W. - Frustrating Lots Of Workers

Any radical change is likely to be trouble, but complete upheaval, of day-to-day operations, is guaranteed to be terrifying and demoralizing. Of course, if wp:Flow become unbearable, then people could always resort to using WP essay pages as talk-pages (essay "Talk of RMS Titanic"). Even the mere suggestion that templates used in wp:FLOW pages would be subst'ed to HTML is horrific. Perhaps the first horror would be a long template that generates extensive markup such as {{bg|#ccc|This}} which shows "This" but would insert "<span style="background-color: #ccc">This</span>" for every {bg} in a Flow page. Then there is also the pesky trouble of including a calculation adding 20 numbers and reducing the talk-text to only the final result, not easy to modify for adjusted numbers. However, the elephant in the room, for subst'ing templates in Flow pages would be the inability to upgrade system-wide style templates to, retroactively, back-apply the new style into older Flow pages. Templates are not just simple typesetting styles, but rather they are the way to quickly update the population counts of 2,700 towns/cities in Austria, by editing just 10 templates. And they are, also, the way to style wp:WikiProject banners, so all pages could show a similar style, even when enhanced to a new system-wide style in the future. In general, people must understand the concept of a macro scripting language and why the word "macro" is so critically important to easily reading and maintaining data in a word-processing system, and remember that talk-pages are in this same word-processing system. Talk-pages are NOT your grandfather's handheld keypad device to be read by millions of people. No instead, talk-pages are word-processing documents styled and formatted to convey a vast array of information, including data tables and graphical charts calculated by templates and Lua script modules. -Wikid77 (talk) 13:52, 4 June 2013 (UTC)

Can you stop fear mongering please ? I mean the world can seize to exist tomorrow, but we don't post 300 word essays about that on this page every day either. Still it would significantly impact our capabilities of working on the encyclopedia. —TheDJ (talk • contribs) 15:44, 4 June 2013 (UTC)

(edit conflict) (false conflict - no other edits)

I am not fear-mongering, and it's not like I said, "FLOW is the secret organization Freakazoid Lunatics Overtake Wikipedia" but I can sense your levels of frustration. I think it would be much more productive to fix the numerous problems with auto-merging of edit-conflicts, both for talk-page replies and for multiple insertions near the same lines in article texts. Some of that work could be called "FLOW" while using the current talk-pages, but with FLOW extensions. Even if the edit-conflicts are not fixed with a formal proof of correctness, yet some heuristic methods could be used to auto-correct most edit-conflicts. I have already noted the need for test-and-set logic, by read-locking the page each time a "new section" is appended, to avoid adding 2 conflicting endings to the same prior revision. Otherwise, wp:FLOW can sound like a scary delusion mistaken about how talk-pages are actually used. The reality is that many talk-pages contain portions of article text, with templates and footnotes, and some cases keep re-revising that text for later use in live articles. Also, people often say, "Edit this talk-page section to see markup" as in $E=mc^{2}$. If you haven't noticed the current fear levels about wp:FLOW, then try rereading those threads. -Wikid77 (talk) 04:38, 5 June 2013 (UTC)

To correct some of the above:

• The expanded HTML won't be visible to users since Flow won't allow you to view or edit the source. Jorm is planning to only allow editing using a cut-down VisualEditor.
• Regular users won't be able to use templates at all, so you won't be able to use {{bg}}. HTML expansion of templates only applies to posts by bots and scripts that use the MediaWiki API.
• WikiProject banners won't be affected since they will be in the non-Flow "unstructured content" at the top of the page. This behaves like regular wiki pages.

We might end up with essay pages being used for talk (or similar). However, since we can't get rid of Flow, this means we'd have fragmented discussions. Some editors would comment using Flow whilst others would comment on essay pages, causing parallel discussions on the same topic. – PartTimeGnome (talk | contribs) 23:06, 4 June 2013 (UTC)

Well, it might be more correct to explain how wp:FLOW will not be able to function, realistically, if it worked according to plans suggested in May 2013. So instead, many WP discussions would likely bypass the FLOW-controlled portions of pages, to post talk-pages messages as before in other areas. -Wikid77 04:38, 5 June 2013 (UTC)

I asked Jorm on IRC and he said that he's not dead-set on disallowing templates – it's just that Flow is going to support whatever VE supports, and it currently doesn't support inserting or modifying templates. But – and this is my own judgment now – it seems to me that the template support will reach useful levels before Flow is anywhere near being fully implemented, so I wouldn't worry about this part too much. Matma Rex talk 19:13, 5 June 2013 (UTC)

And Brandon achieved what he intended: No one worries anymore up to the day FLOW is due and editors recognize I didn't work as expected. Sorry, Matma Rex, but Brandon mentioned often enough that templates and the like will be most likely gone. I don't believe such excuses that easy. --Patrick87 (talk) 19:53, 5 June 2013 (UTC)

But is he still planning to disable the source editor for discussion pages? Given that I can't use VisualEditor, that's a bit of a big one for me... – PartTimeGnome (talk | contribs) 20:39, 5 June 2013 (UTC)

Presumably, there has been a gap analysis to compare what talk pages are used for now with what the new platform can provide. Can we see that please?

In particular, there's talk about whether templates will be allowed or not. Is it just templates or all Wiki markup? One of the primary purposes of talk pages is to talk about their linked pages. In order to discuss edits to the main page, you need to be able to reproduce those edits as closely as possible in the talk page. This includes basic things like text style, size, color, etc. and well as linking to other wiki pages (in various namespaces), interwiki links, and links to web pages. If these are not supported with the same syntax as now, can't they be made to be? If they're not supported at all, of course, it seems like a non-starter.

There are lots of templates that are used to make discussions more clear ({{tl*}}, {{bg}} et. al., {{in5}}, {{done}}, off the top of my head; some not-so-important ones). Are there replacements for each of them?

I'm all for making it easier for newbies to use talk pages, and solving the threading/indenting issues that are now so confusing to them (and us), but, at the core of it, these pages are still about editing wiki pages and, to implement them without wiki markup seems like it will always provide less than what is needed. —[AlanM1(talk)]— 22:32, 9 June 2013 (UTC)

Re: gap analysis: See mw:Flow Portal/Use cases and the other pages linked in the sidebar there.

Re: templates, I'm not sure, but given that it's still being designed at the moment, I'm sure we'll be able to influence the direction it grows in, and the features that it includes. Mediawiki is the preferred place for those discussions (ie where Jorm is most likely to see them). –Quiddity (talk) 23:28, 9 June 2013 (UTC)