Jump to content

User talk:SlimVirgin: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
SlimVirgin (talk | contribs)
172,064 edits
Line 164: Line 164:


::::::Thank you, it's very helpful. Could you say what you mean by this? "A simpler template that displayed ten parameters would not do nearly as much work as one that makes complex decisions based on ten parameters." So there could be citation templates that display the same number of parameters, but which work differently and wouldn't cause these problems? I know people have suggested alternatives, but I'm never sure why they're not taken up. [[User:SlimVirgin|SlimVirgin]] <small><sup>[[User_talk:SlimVirgin|(talk)]]</sup></small> 20:30, 29 August 2012 (UTC)
::::::Thank you, it's very helpful. Could you say what you mean by this? "A simpler template that displayed ten parameters would not do nearly as much work as one that makes complex decisions based on ten parameters." So there could be citation templates that display the same number of parameters, but which work differently and wouldn't cause these problems? I know people have suggested alternatives, but I'm never sure why they're not taken up. [[User:SlimVirgin|SlimVirgin]] <small><sup>[[User_talk:SlimVirgin|(talk)]]</sup></small> 20:30, 29 August 2012 (UTC)
:::::::Yes there could be templates that have the same number of parameters, which work differently with less problems. This is because the sheer number of parameters is not the only contributor to increased processing time. The number of ''if-then-else'' decisions made based on each parameter is a contributor to complexity, so if a template had only rudimentary intelligence regarding which parameters to hide and show, it would run faster. The "smarter" a many-parameter template gets, the greater the need becomes for optimizations like the one Gimmetoo describes. In general it isn't an issue, but it seems like with the citation templates it has become one. There are definitely ways that the citation templates can be made faster, but my first concern is that a change to the template interface would require checking usages of the template across the entire project to make sure they're not being broken by template optimizations. In the end it would be faster to create a whole new set of citation templates in parallel, rather than to try to change these ones with their millions of transclusions. Then we could systematically replace the old set with new, faster ones. When replacing millions of template calls is the easy way, you know it's going to be a lot of work. One of us should probably phone [[Skynet (Terminator)|Skynet]] and make an order for more bots. [[User:BigNate37|BigNate37]]<sub>[[User talk:BigNate37|(T)]]</sub> 16:29, 30 August 2012 (UTC)


Sorry to follow wikid77 here, but here are some more specific examples. In citation/core, there is a parameter called "Surname1". We don't use citation/core directly, however, but through other templates like cite web. When cite web "invokes" citation/core, it uses the following logic to determine what to use for Surname1 based on the parameters used to invoke "cite web": if "last=" is used, use it, otherwise if "surname=" is used, use it, otherwise if "last1" is used, use it, otherwise if "surname1" is used, use it, otherwise if "author1" is used, use it, otherwise if "author" is used, use it, otherwise if "authors" is used, use it, otherwise use Surname1=<blank>. If someone writes cite web with authors=Smith, Jones, then every other possible "alias" needs to be "checked" before checking authors= for Smith, Jones. On the other hand, every template that uses last=Smith doesn't need to "check" the other parameters. Even a fairly common alias like "author" requires checking 5 other parameter names first. Next, cite web includes a number of "identifier" options, including DOI, ISBN, ISSN, JSTOR, ARXIV, LCCN, OCLC, SL, RFC, SSRN, and many others. Every one of these involves *some* logic (usually checking lowercase then uppercase, such as "isbn", then "ISBN" as parameter options for ISBN), and every one gets passed on to citation/core, but most are rarely used (and some don't even make sense with cite web). Wikid77 above suggests a gateway option, like idkey, so that these parameters would only be checked if idkey=yes to begin with. This would add one bit of logic to every "invocation" that had an id of some sort, but for every invocation that had "idkey=no", the code could skip all the logic for DOI, ISBN, etc. (There are other ways to optimize that logic, too.). All this logic is processed either with a save, or with a preview. Simple reading of the latest version uses a "cached" version that has already been processed, so it generally goes faster, often much faster. [[User:Gimmetoo|Gimmetoo]] ([[User talk:Gimmetoo|talk]]) 02:09, 28 August 2012 (UTC)
Sorry to follow wikid77 here, but here are some more specific examples. In citation/core, there is a parameter called "Surname1". We don't use citation/core directly, however, but through other templates like cite web. When cite web "invokes" citation/core, it uses the following logic to determine what to use for Surname1 based on the parameters used to invoke "cite web": if "last=" is used, use it, otherwise if "surname=" is used, use it, otherwise if "last1" is used, use it, otherwise if "surname1" is used, use it, otherwise if "author1" is used, use it, otherwise if "author" is used, use it, otherwise if "authors" is used, use it, otherwise use Surname1=<blank>. If someone writes cite web with authors=Smith, Jones, then every other possible "alias" needs to be "checked" before checking authors= for Smith, Jones. On the other hand, every template that uses last=Smith doesn't need to "check" the other parameters. Even a fairly common alias like "author" requires checking 5 other parameter names first. Next, cite web includes a number of "identifier" options, including DOI, ISBN, ISSN, JSTOR, ARXIV, LCCN, OCLC, SL, RFC, SSRN, and many others. Every one of these involves *some* logic (usually checking lowercase then uppercase, such as "isbn", then "ISBN" as parameter options for ISBN), and every one gets passed on to citation/core, but most are rarely used (and some don't even make sense with cite web). Wikid77 above suggests a gateway option, like idkey, so that these parameters would only be checked if idkey=yes to begin with. This would add one bit of logic to every "invocation" that had an id of some sort, but for every invocation that had "idkey=no", the code could skip all the logic for DOI, ISBN, etc. (There are other ways to optimize that logic, too.). All this logic is processed either with a save, or with a preview. Simple reading of the latest version uses a "cached" version that has already been processed, so it generally goes faster, often much faster. [[User:Gimmetoo|Gimmetoo]] ([[User talk:Gimmetoo|talk]]) 02:09, 28 August 2012 (UTC)

Revision as of 16:29, 30 August 2012

Selena Gomez

Hey I'd like to updating your image in Selena Gomez page with the latest picture of her in 2012. Thank you :) — Preceding unsigned comment added by TiraSadiyah (talk • contribs) 08:16, 22 August 2012 (UTC)[reply]

Vote Pi in the next AfD

Vote Pi in the next AfD
Pi means neutrally keep. Anna 23:14, 29 July 2012 (UTC)[reply]

Resource exchange

Hello.Your request was fulfilled.You can find a link to the article/s you requested in the relevant section at WP:RX.Please indicate when you've downloaded successfully and add a resolved tag to your request.Thank you.--Shrike (talk)/WP:RX 05:16, 1 August 2012 (UTC)[reply]

YRC

Hey SV. Please have a talk with YRC; his temper is flaring up again, and he's heading for trouble. — Coren (talk) 03:19, 3 August 2012 (UTC)[reply]

That RFC isn't going to proceed well, I predict. Uncle G (talk) 11:35, 6 August 2012 (UTC)[reply]

The Tea Leaf - Issue Five

Stop by for a tasty glass of wiki-iced tea at the Teahouse, today!

Hi! Welcome to the fifth edition of The Tea Leaf, the official newsletter of the Teahouse!

  • Guest activity increased in July. Questions are up from an average of 36 per week in June to 43 per week in July, and guest profile creation has also increased. This is likely a result of the automatic invite experiments we started near the end of month, which seeks to lessen the burden on hosts and other volunteers who manually invite editors. During the last week of July, questions doubled in the Teahouse! (But don't let that deter you from inviting editors to the Teahouse, please, there are still lots of new editors who haven't found Teahouse yet.)
  • More Teahouse hosts than ever. We had 12 new hosts sign up to participate at the Teahouse! We now have 35 hosts volunteering at the Teahouse. Feel free to stop by and see them all here.
  • Phase two update: Host sprint. In August, the Teahouse team plans to improve the host experience by developing a simpler new-host creation process, a better way of surfacing active hosts, and a host lounge renovation. Take a look at the plan and weigh in here.
  • New Teahouse guest barnstar is awarded to first recipient: Charlie Inks. Using the Teahouse barnstar designed by Heatherawalls, hosts hajatvrc and Ryan Vesey created the new Teahouse Guest Barnstar. The first recipient is Charlie Inks, for her boldness in asking questions at the Teahouse. Check out the award in action here.
  • Teahouse was a hot topic at Wikimania! The Teahouse was a hot topic at Wikimania this past month, where editor retention and interface design was heavily discussed. Sarah and Jonathan presented the Teahouse during the Wikimedia Fellowships panel. Slides can be viewed here. A lunch was also held at Wikimania for Teahouse hosts.

As always, thanks for supporting the Teahouse project! Stop by and visit us today!

You are receiving The Tea Leaf after expressing interest or participating in the Teahouse! To remove yourself from receiving future newsletters, please remove your username here. Sarah (talk) 08:38, 4 August 2012 (UTC)[reply]

Marshalsea and Outlawry

Hello Slim, response to you on here- Kind regards, J2013 — Preceding unsigned comment added by Jennifer2013 (talk • contribs) 14:44, 4 August 2012 (UTC)[reply]

License tagging for File:Alfred Wetzler.JPG

Thanks for uploading File:Alfred Wetzler.JPG. You don't seem to have indicated the license status of the image. Wikipedia uses a set of image copyright tags to indicate this information.

To add a tag to the image, select the appropriate tag from this list, click on this link, then click "Edit this page" and add the tag to the image's description. If there doesn't seem to be a suitable tag, the image is probably not appropriate for use on Wikipedia. For help in choosing the correct tag, or for any other questions, leave a message on Wikipedia:Media copyright questions. Thank you for your cooperation. --ImageTaggingBot (talk) 00:05, 6 August 2012 (UTC)[reply]

credo

I saw your post on the Credo page .. does it go to the first person on the list? Or the first person to ask? :-) — Ched :  ?  23:38, 7 August 2012 (UTC)[reply]

Hi Ched, I don't know. When I was last dealing with this, there was a Credo contact person who redistributed the accounts, but I see Ocaasi removed that name today, so the best thing would be to ask him. He has arranged for some additional subscriptions too, so I am guessing that all or most who want one will get one. SlimVirgin (talk) 00:43, 8 August 2012 (UTC)[reply]
Thank you ma'am. Just for my own future reference, do you object to use of "Slim" or "SV" when referring to this account? I've seen both used, but never noticed any objection before - but thought it would be polite to ask. Cheers and best. — Ched :  ?  07:50, 8 August 2012 (UTC)[reply]
Slim or SV are both fine, Ched. :) SlimVirgin (talk) 00:15, 9 August 2012 (UTC)[reply]
Hi SV! We're indeed going through a new sign-up in August which I am helping coordinate with Credo. Ched, if you just add your name to the sign-up list, it will be close to the top. With approximately 125 new accounts available I don't foresee a problem. One quick question: It wasn't clear from the archives if there was an editor time or edit count criterion for the original sign-up. I'd like to be consistent with this new round; do you know what the initial criteria were, if any? Cheers, Ocaasi t | c 11:53, 8 August 2012 (UTC)[reply]
Hi, the first time it was just first come, first served, and the second time we used the criteria here. By the way, you're doing some brilliant work organizing all these subscriptions, Ocaasi. It's really appreciated. SlimVirgin (talk) 00:15, 9 August 2012 (UTC)[reply]
Hi Ocassi - already there in the top 10. There may be a name-change involved, but I'll amend that if and when that time comes. Thank you. — Ched :  ?  13:42, 8 August 2012 (UTC)[reply]

Compromise as Cite_quick

I am working on another fast-cite compromise, as Template:Cite_quick (12x faster or 175/second), which supports only the major parameters (as with pop-culture cites) and lists all parameters not supported. As you might have noticed, the TfD for Template:Fcite was closed as, basically, "Don't delete don't use" which is nonsense akin to an AfD as "Keep don't read" or "Keep but text visibility none". See TfD:

Unfortunately, I was out of town when closing admin User:Plastikspork closed the TfD as "but not deployed in articles" along with closing dozens of other TfD entries. I have been on wikibreak, and Plastikspork has been on wikibreak, so the TfD nonsense has locked the templates for 4 weeks. Meanwhile, the "spirit of the consensus" was to improve the {Cite} family with {Cite_web}, etc. So, the next compromise is {{Cite_quick}} for minimal cites in pop-culture articles. However, this approach has the benefit of exceeding the 6x-faster Fcite templates as 12x faster, due to omitting most parameters, but limited to short, simple cites. Long-term, the {Fcite_journal} is intended as 5x-faster for most medical articles, supporting numerous journal codes (arxiv, ASIN, bibcode, DOI, OSTI, OCLC, PMC, PMID, SSRN, etc.) and interactions with Cite tools. Anyway, {Cite_quick} is intended to allow progress this week. Among the debates, many people did not realize major articles preview so slowly, or that cites could be formatted 6x-12x faster, as edit-preview of 5-10 seconds rather than 20-40 seconds. People have been replying like, "Is that some other definition of 'second'?" Hence, it is not just gaining consensus to use different templates, but to even understand how hundreds of major articles (pageviews > 5,000/day), and their prior revisions, have been reformatting so slowly, for over 3 years. -Wikid77 (talk) 06:28, 8 August 2012 (UTC)[reply]

Hi, thanks for keeping me informed about this. I'll leave a note on your talk page at some point, as I have a few questions, but just wanted to say in the meantime that I continue to be puzzled that people don't realize how slowly pages having been loading (especially diffs and preview) for years with these old templates. It raises lots of interesting questions. SlimVirgin (talk) 00:15, 9 August 2012 (UTC)[reply]
  • Many people rarely view the slow articles to learn about speed: Part of the problem is because most people rarely edit major articles, so they do not realize "Israel" takes 42 seconds to edit-preview, or "Beyonce" runs 26 seconds to reformat a common pop-culture article. Several people have asked, "Are these faster claims real, or just local to your PC?" as if there were no need to make "The System" as a whole, faster. However, after running hundreds of time-tests, I must conclude the speed issues are a complex study, with shocking aspects. One major shock was seeing, every day, the "Double-slow penalty" when, every so often, a page formats almost twice as slowly (compared to the average), so a page average of 6 seconds sometimes increases to about 12. Think of the danger: an average of 26 seconds (Beyonce) becomes about 50 seconds, but 42 seconds (Israel) becomes 80, where any reformat longer than 60 seconds causes "wp:Wikimedia Foundation error" (MF-error) and totally loses the edit-preview. The implication is clear: a shorter reformat time of 7 seconds never exceeds 14, and 25 occasionally approaches 50 seconds, but any page >35 seconds risks becoming 70. Hence, any page >30 seconds means a potential to hit MF-error of 60-second timout. So, when editing, if the page is slow beyond 30 seconds, prepare to someday lose an edit due to Mediawiki Foundation error. It's not random failure; it's predictable science: an average reformat time <30 means no danger of MF-error. These rarely known issues are why people misunderstand the speed of articles. No one is warning users: Beware, articles with edit-preview >30 can die with MF-error. So the speed is more than "personal preference" for quick. No, a page reformatting >30 can die totally, not just a personal preference to wait a few seconds longer. Only by "Worrying about performance" did we learn such major issues, and have a plan to avoid MF-error from ruining edit-preview, or SAVE, of large articles, by reducing average reformat time to <30 seconds. -Wikid77 (talk) 13:12, 14 Aug., revised 00:25, 17 August 2012 (UTC)[reply]
  • The thing is that so many articles are slow to load because of citation templates (not just the biggies) that it's quite disturbing to note that regular Wikipedians go year after year without noticing the slowdown. I've frequently been told it's just my computer that's the issue, though I've edited from desktops and laptops, Windows and Mac, and with different user preferences. I can't explain people's resistance to even identifying this as a serious problem, much less their resistance to fixing it. Julian Assange is another one, by the way. Important article, should be easy to load. Just took me 20 seconds to access it, 18 seconds to pull up a diff, 18 seconds to load preview. So it is effectively un-editable, except to make the occasional single edit, or quick series of edits. But any attempt to copy edit, for example – where you need to use preview multiple times – would be a miserable job, thanks to 262 citation templates (up to six after one sentence). SlimVirgin (talk) 00:36, 15 August 2012 (UTC)[reply]
  • Fixing Assange and resistance: I have preferences set to show cache pages, but "Assange" also took "18.002 secs" (not 0.250) for me to access, obviously bypassing cache but not edited in 3 hours, while other articles showed cache-page copies. That's another performance shock for me: one article bypasses cache. I cleared my entire browser cache, and then Assange showed the cache-page copy. As for broad resistance, the Continuous Improvement movement (Kaizen, etc.) has warned, "People dislike change". Most act like the "boiling frog" and sit while the temperature rises, never moving until too late and "Beyonce" runs 26 seconds (or Assange 18). I advised Jimbo, to add "More pillars" where Performance becomes a major priority, like Civility or NPOV, rather than "personal preference to see results" in the same hour, while they demand the cite-tools still work. You might know I've had severe rejections trying to defuse essay wp:PERF, and explain how the Titanic sank because "Don't worry" thwarted other people from acting or improving (the ship design included ample lifeboats rejected by others). This year, with the Costa Concordia in Italy, passengers worried enough about the tilting ship to call land-based police to complain the ship seemed damaged while crew pretended "Don't worry". Enough. I think we are reaching "critical mass" to move forward here. The next compromise consensus supports all parameters (as demanded pronto), and auto-runs the quick citations, with later promises to "fix" {Citation/core} where possible, and still support those cite-tools which generate {cite_web} calls and such. It is a hideously complex upgrade, with over 23 forks as {cite_book}, {cite_video}, {cite_document}, {cite_press_release}, {cite_encyclopedia}, even "{citeweb}" or "{cite web}" but fixing the most-used will cure the speed problems. Plus, the talk-page already warns to deprecate "surname1" for "last1" where 3 fewer alias parameters could mean 2x faster for that parameter, perhaps next year. Beyond the complex fast {Fcite} templates, the rapid {cite_quick} runs 10x-12x faster, so "Assange" can drop from 18 to 5-second edit-preview. I already saved some temporary revisions to "prove" Assange can reformat in 5 seconds:
  • Assange 03:32, 15 August 2012‎ Wikid77 (talk | contribs)‎ . . (126,986 bytes) (-1,526)‎ . . (undid 2nd prior revision to compare performance & confirm edit-preview returns to 18 seconds, when not using Template:Cite_quick.)
  • Assange 03:28, 15 August 2012‎ Wikid77 (talk | contribs)‎ . . (128,512 bytes) (+4)‎ . . (+past-tense verb "has published")
  • Assange 03:23, 15 August 2012‎ Wikid77 (talk | contribs)‎ . . (128,508 bytes) (+1,526)‎ . . (used Template:Cite_quick in 218 cases to reduce the edit-preview, or reformat, time from average 18 seconds to 5 seconds.)
  • Assange 23:56, 14 August 2012‎ Kennvido (talk | contribs)‎ m . . (126,982 bytes) (-1)‎ . . (→‎Request for political asylum)
Every time an old revision is clicked, it is reformatted for the viewer, even if viewed just seconds earlier, and so those revisions use the latest templates. Above, the middle revisions (03:23, 03:28) reformat in 5 seconds each, but rev. 03:32 takes about 18 secs, confirm a cause-effect between faster reformat and using {cite_quick} in the 2 middle revisions. As long as several of us continue working together, even part-time, I think we can solve the speed problems soon, and set some precedents to solve other performance problems which people were warned don't-worry about (see my essay: wp:DOWORRY). Naturally, some people might be embarrassed to have fought the improvements, so that has also slowed progress, to keep a lower profile. -Wikid77 (talk) 06:24, 15 Aug., revised 00:25, 17 August 2012 (UTC)[reply]
  • Assange page-cache okay now: After the shock of seeing the Assange article reformat in 18.002 secs when first accessed, now it has been showing the page-cache copy for 2 days (0.230-0.255 secs), when I delete browser temp files & redisplay. Perhaps the earlier reformat was related to "replication lag" in the servers, so that an article edited only 3 hours earlier might still reformat on some replication servers, but then save a page-cache copy when the replication is completed? From what I have seen, every page when first viewed by one person has a unique process-time "Served by srv999 in 0.252 secs" where a page-cache copy is run (in 0.100-0.900 secs) every time any reader wants an article, but the prior revisions (or edit-preview) are always active reformats "Served by srv999 in 9.999 secs". The key point is that the short process-time "0.252 secs" to copy a page-cache, of the top revision, is different for every reader's copy of an article, whenever a page is first viewed, or every time any prior revision is viewed, again and again. Prior revisions always use the current revisions of templates. -Wikid77 00:25, 17 August 2012 (UTC)[reply]

New project

Hey Sarah! I'd love your input on the project I am in the process of starting. If you have time to take a look, especially at the questions on the talk page, that'd be fabulous. Thank you! SarahStierch (talk) 21:38, 8 August 2012 (UTC)[reply]

Thanks for letting me know, Sarah, I'll take a good look through it later. SlimVirgin (talk) 00:15, 9 August 2012 (UTC)[reply]

Your edit at Gynandromorphophilia.

Hi, SV; I hope you are well.

Could you expand on your deletion of the material? It is extremely well sourced, most of the text is exactly from the WP bio about her (as wikilinked), and the topic is highly germane to the stigma associated with the topic of the page. What's the BLP issue?— James Cantor (talk) 21:47, 8 August 2012 (UTC)[reply]

Quick blp question

I wanted to ask you a question in regard to the Pussy Riot article. I've marked the talkpage of the article with {{blp}} because the article has a sub-section entitled "The defendants" which gives personal details about several members of the group. I don't have much blp experience, as I usually deal with long-dead writers and poets. Is marking the talkpage enough, or is something more needed in regard to the article page itself? Thanks for your time. INeverCry 19:20, 11 August 2012 (UTC)[reply]

WP:BLP applies to all articles that have biographical material about a living person. Based on my limited knowledge of Pussy Riot, it looks like you did the right thing. A Quest For Knowledge (talk) 19:23, 11 August 2012 (UTC)[reply]
Thanks. I just wanted to make sure there wasn't something more that needed to be done. INeverCry 19:59, 11 August 2012 (UTC)[reply]
Hi, that was the right thing to do. Unless there are BLP problems with the article, tagging the talk page is enough. After a very quick glance through the article I couldn't see any obvious BLP issues (though any material about a living person needs to be sourced per WP:BLPSOURCES, and I didn't check the sources). Best, SlimVirgin (talk) 20:45, 11 August 2012 (UTC)[reply]
Thanks for the quick answer. Much appreciated. INeverCry 21:47, 11 August 2012 (UTC)[reply]

I hope you don't mind another question. There's a section on the Pussy Riot talk page entitled "Gang Bang, offending the Patriarch and blasphemy", in which there doesn't seem to be any reliable ref for what's being said. Isn't this a blp violation itself, and shouldn't it be removed? INeverCry 17:54, 12 August 2012 (UTC)[reply]

TfD for new Cite_web/smart

I am contacting you, per wp:CANVAS, after contacting mostly negative editors, as a user previously supportive of quick, fast citation templates, in considering the latest TfD discussion. In this case, the template {Cite_web/smart} is finally the big upgrade to entirely replace {Cite_web} with a faster version that cleverly checks the parameters to only invoke {Citation/core} for any rare parameters, else quickly formats a cite. See TfD of 11 August 2012:

This notice is only an FYI, as announcing the discussion under way. Feel free to oppose the template, support the template, ignore the discussion, or even delete this message. The TfD just started, so there should be, at least, 7 days to consider the issues. Thanks. -Wikid77 (talk) 21:07, 11 August 2012 (UTC)[reply]

Rfc on Youreallycan/Off2riorob

You may be interested in commenting on this this RfC. A prior decision you made to unblock this editor has been mentioned.--The Devil's Advocate (talk) 16:46, 13 August 2012 (UTC)[reply]

Favour?

Hi SV. Do you have the necessary permissions to erase this, or at least the edit summary? I'm going to bed now; anything you could do would be appreciated. --Anthonyhcole (talk) 22:22, 14 August 2012 (UTC)[reply]

On what grounds, I wonder? Sleep well. pablo 22:46, 14 August 2012 (UTC)[reply]
Hi, the comment and in particular the edit summary were ill-advised, but I'm sorry Anthony, it doesn't (in my view) rise to the level of needing to be admin-deleted. I see you've reverted it now anyway. SlimVirgin (talk) 01:43, 15 August 2012 (UTC)[reply]
Thanks. I'd seen it done before but don't know what the rules governing it are. --Anthonyhcole (talk) 06:33, 15 August 2012 (UTC)[reply]

resource request

Hi,

I've uploaded an article you requested at the resource exchange. You can find a link to the article on that page. Best, GabrielF (talk) 05:09, 16 August 2012 (UTC)[reply]

Thanks, Gabriel! SlimVirgin (talk) 05:12, 16 August 2012 (UTC)[reply]

Hi. When you recently edited Kastner train, you added a link pointing to the disambiguation page Bergen-Belsen (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 04:44, 19 August 2012 (UTC)[reply]

Orphaned non-free media (File:JoelBrand.jpg)

Thanks for uploading File:JoelBrand.jpg. The media description page currently specifies that it is non-free and may only be used on Wikipedia under a claim of fair use. However, it is currently orphaned, meaning that it is not used in any articles on Wikipedia. If the media was previously in an article, please go to the article and see why it was removed. You may add it back if you think that that will be useful. However, please note that media for which a replacement could be created are not acceptable for use on Wikipedia (see our policy for non-free media).

If you have uploaded other unlicensed media, please check whether they're used in any articles or not. You can find a list of 'file' pages you have edited by clicking on the "my contributions" link (it is located at the very top of any Wikipedia page when you are logged in), and then selecting "File" from the dropdown box. Note that all non-free media not used in any articles will be deleted after seven days, as described on criteria for speedy deletion. Thank you. Hazard-Bot (talk) 04:01, 20 August 2012 (UTC)[reply]

circular reference

You reverted a needed change. WP:PRIMARY and WP:BLPPRIMARY do not agree with each other and also refer to each other for further information. I can understand not liking my particular attempt at reconciling them but they do need to be reconciled. TMLutas (talk)

Hi, they are supposed to be different, and WP:PRIMARY does say that BLPs need extra caution. We could perhaps clarify in the BLP policy that they are not intended to be the same, but it's best to continue discussing that on WT:BLP. Also, if you look at that talk page, you'll see a recent RfC produced consensus not to change that section. SlimVirgin (talk) 17:54, 20 August 2012 (UTC)[reply]

RFPP for Carl Hewitt

Hello,

There's been a request for unprotection on Carl Hewitt. While you were not the last admin to protect the article, that admin has suggested that you provide input. I briefly looked in the log and it looks like it is a combination of a BLP issue, possibly ArbCom (mentioned in the protection log), inappropriate moves, etc....very messy. But, it has been full protected for over a year, which probably merits some sort of review as to whether the protection is still warranted. Would you mind taking a look at the page and considering an unprotection? ⇒SWATJester Son of the Defender 01:50, 25 August 2012 (UTC)[reply]

Hi, thanks for letting me know. I've left a note on RfPP. SlimVirgin (talk) 16:22, 26 August 2012 (UTC)[reply]

Why Citation/core is slow

There are 2 major reasons why {Citation/core} runs so slowly: too many top-level options, and too many alias parameters.

  • Too many alias parameters: When {cite_web} invokes {Citation/core}, it has been passing over 210 parameters, many of them aliases, such as for "author" with 6 aliases: author1, last1, last, surname1, surname, or authors (plural). The overall effect of those 210 parameters is to cause {cite_web} to run 2x (twice) as slow as {Citation/core} separately. In fact, new Template:Cite_fast, with only 50 parameters passed to {Citation/core}, runs almost twice as fast as {cite_web}, indicating that, while 50 parameters could be processed fairly quickly, by the time it reaches 210 parameters (4x as many), then processing slows to half the speed. Note well: it is fine for a massive {Citation/core} to handle many parameters, but not all passed all the time, nor all handled as top-level options.
  • Too many top-level options: Many parameters of {Citation/core} are checked every single time it is invoked, even though 98% of citations never use those options, such as medical PMID id being checked in all of 1.6 million articles using {Citation/core}, most non-medical. If, instead, there were new "gateway options" such as default "idkey=no" to bypass checking of numerous id codes (ASIN, arXiv, bibcode, DOI, ID, LCCN, ISBN, ISSN, MR, OCLC, OL, OSTI, PMC, PMID, RFC, SSRN, ZBL, etc.), then much time could be saved. Currently, {Citation/core} has few "gateway options" (as if "idkey=yes" always, to check for 35 id codes even when they are all empty).

Another faster gateway option could be "names=no" to skip checking for the 23 major name aliases (author, author1, last1, last, surname1, surname, first1, first, given1, given, authors, coauthors, coauthor, others, editor, editor1, editor-last, editor1-last, editor1-surname, editor-surname, editor-first, editor1-first, or editors). Note here, a template can be huge, and handle numerous parameters, if they are grouped in efficient groups only triggered by top-level gateway options which could quickly bypass checking for numerous unused options, and their many alias names. However, currently, when all options are constantly checked, as top-level options, then {Citation/core} runs very slowly, methodically seeing if any rare option has been used, everytime. I hope that explains the current slow processing. -Wikid77 (talk) 06:41, 27 August 2012 (UTC)[reply]

  • Thanks, Wikid. I'm afraid I understand very little of it. For example: "Many parameters of {Citation/core} are checked every single time it is invoked, even though 98% of citations never use those options, such as medical PMID id being checked in all of 1.6 million articles using {Citation/core} ..." What do you mean by "checked" and "invoked"? Also, is there anything that can be done about this at the Foundation (server) end? SlimVirgin (talk) 18:32, 27 August 2012 (UTC)[reply]
  • WMF plans to add Scribunto Lua cite-modules: Although {cite_quick} is already documented and can solve the slow-citation problem for many major articles, there are alternate plans to rewrite the 23 forks of {cite_web}, {cite_book}, {cite_press_release}, {cite_video}, {cite_podcast} (etc.) with "Module:Citation" written in the Lua scripting language, and access via the MediaWiki Scribunto language interface. The Meta page about Scribunto is: meta:Extension:Scribunto. The use of Lua scripting in Module pages (versus Template pages) is another avenue for better speed. However, I think there is still a severe limit to speed even in Lua, so now the Lua modules will need to be carefully developed, with more speed tricks, such as already used in {cite_quick} or {Fcite_journal}. Yet, the whole installation of Lua means that the Foundation agrees there "might be a speed problem" versus some people who say, "Why worry about 12 seconds longer, does any editor, or reader, use Wikipedia enough to care about such speeds?" There are numerous editors who cannot even imagine editing over 5,000 articles, tops, much less rewriting an entire large article, with 400 tedious edit-previews of changes. -Wikid77 (talk) 19:38, 27 August 2012 (UTC)[reply]
  • That's the thing I find most puzzling -- that this can go on for years, and very few people seemed to mind or even notice (until recently), which suggests that a lot of them are not editing articles, or at least not adding a lot of content, and may not even be reading them. If you have to wait 15-30 seconds for each preview and diff, and you might have to preview dozens of times, it quickly becomes impossible.

    Could you explain the thing about parameters being checked and invoked? I would love to understand what that means (if you have time)? SlimVirgin (talk) 19:51, 27 August 2012 (UTC)[reply]

    • An invocation, in this context, is referring to when the software loads a template. The software "invokes" the template, i.e. looks up its template code, parses it, and turns it into HTML for display. When a template like {{cite web}} passes along most of its work to {{citation/core}}, you could say that {{cite web}} invokes {{citation/core}}. Checking in this context refers to reading a parameter, evaluating a conditional expression, and possibly performing some action based on the result of the evaluation. For example, the citation templates need to check whether page numbers have been provided, and affix p. or pp. if so. If a set of rarely-used parameters are individually "checked" every time a template is loaded, this represents a waste of processing time. A flag parameter may be used in cases like this, so that the template only needs to check one parameter (the flag), and if the flag indicates that the group of rarely-used parameters can be safely ignored, the template moves on and saves much time (though this would slightly add to the time to check these parameters in the instances where they are used, so this type of trick should be applied with care). I hope this helps, I just happened upon this conversation while passing through. BigNate37(T) 23:18, 27 August 2012 (UTC)[reply]
  • Thank you for explaining that. I always feel like such an idiot when I'm trying to understand this (I don't have the vocabulary, can barely grasp the concepts, etc). So if an article contains 200 citation templates, and each template contains 10 parameters -- even if, say, six of them have been left empty -- is the software having to "check" 2000 parameters before the page can be loaded? Also, why are preview and diffs so much slower than loading the page in read mode? SlimVirgin (talk) 23:31, 27 August 2012 (UTC)[reply]
No problem. And no reason to feel like an idiot: ignorance does not begin until one stops asking questions. It's more impressive to admit what you don't know than to be a know-it-all. Anyways, yes, your example of 200x10 is correct, given certain assumptions. The citation templates add extra formatting for each parameter that is used, so they not only show the parameter, but they also have to perform logic for each parameter as well. A simpler template that displayed ten parameters would not do nearly as much work as one that makes complex decisions based on ten parameters.
As far as previews and edits taking longer to load than page views, I think this is mostly because of caching (but I am not certain that there is not also another cause): when a MediaWiki page is requested, the page is composed (all templates being invoked) and the resulting HTML is saved on the servers and a copy is given to everyone who views that page. This is why we sometimes need to purge pages: this tells the MediaWiki software that it's generated view of a page is no longer valid, and it's forced to generate a fresh view of the page. Normally it knows to do this automatically in obvious cases, like if the page was edited. Sometimes it's needed manually, for instance if a template used on the page has changed but still appears as the old version, or if a category isn't properly reflecting changes in the pages that it contains. Meta:cache strategy and WP:PURGE shed a little bit of light into this. When you're previewing an edit, it's impossible to have already had a view of that page saved, because it did not exist prior to your session. Diffs don't seem to be cached either, and though though it would be possible to cache views of history diffs, it is probably not done on the basis of a cost/benefit analysis.
I hope that helps. Sometimes it's hard to judge how much detail to include and how much knowledge to assume. BigNate37(T) 00:13, 28 August 2012 (UTC)[reply]
Thank you, it's very helpful. Could you say what you mean by this? "A simpler template that displayed ten parameters would not do nearly as much work as one that makes complex decisions based on ten parameters." So there could be citation templates that display the same number of parameters, but which work differently and wouldn't cause these problems? I know people have suggested alternatives, but I'm never sure why they're not taken up. SlimVirgin (talk) 20:30, 29 August 2012 (UTC)[reply]
Yes there could be templates that have the same number of parameters, which work differently with less problems. This is because the sheer number of parameters is not the only contributor to increased processing time. The number of if-then-else decisions made based on each parameter is a contributor to complexity, so if a template had only rudimentary intelligence regarding which parameters to hide and show, it would run faster. The "smarter" a many-parameter template gets, the greater the need becomes for optimizations like the one Gimmetoo describes. In general it isn't an issue, but it seems like with the citation templates it has become one. There are definitely ways that the citation templates can be made faster, but my first concern is that a change to the template interface would require checking usages of the template across the entire project to make sure they're not being broken by template optimizations. In the end it would be faster to create a whole new set of citation templates in parallel, rather than to try to change these ones with their millions of transclusions. Then we could systematically replace the old set with new, faster ones. When replacing millions of template calls is the easy way, you know it's going to be a lot of work. One of us should probably phone Skynet and make an order for more bots. BigNate37(T) 16:29, 30 August 2012 (UTC)[reply]

Sorry to follow wikid77 here, but here are some more specific examples. In citation/core, there is a parameter called "Surname1". We don't use citation/core directly, however, but through other templates like cite web. When cite web "invokes" citation/core, it uses the following logic to determine what to use for Surname1 based on the parameters used to invoke "cite web": if "last=" is used, use it, otherwise if "surname=" is used, use it, otherwise if "last1" is used, use it, otherwise if "surname1" is used, use it, otherwise if "author1" is used, use it, otherwise if "author" is used, use it, otherwise if "authors" is used, use it, otherwise use Surname1=<blank>. If someone writes cite web with authors=Smith, Jones, then every other possible "alias" needs to be "checked" before checking authors= for Smith, Jones. On the other hand, every template that uses last=Smith doesn't need to "check" the other parameters. Even a fairly common alias like "author" requires checking 5 other parameter names first. Next, cite web includes a number of "identifier" options, including DOI, ISBN, ISSN, JSTOR, ARXIV, LCCN, OCLC, SL, RFC, SSRN, and many others. Every one of these involves *some* logic (usually checking lowercase then uppercase, such as "isbn", then "ISBN" as parameter options for ISBN), and every one gets passed on to citation/core, but most are rarely used (and some don't even make sense with cite web). Wikid77 above suggests a gateway option, like idkey, so that these parameters would only be checked if idkey=yes to begin with. This would add one bit of logic to every "invocation" that had an id of some sort, but for every invocation that had "idkey=no", the code could skip all the logic for DOI, ISBN, etc. (There are other ways to optimize that logic, too.). All this logic is processed either with a save, or with a preview. Simple reading of the latest version uses a "cached" version that has already been processed, so it generally goes faster, often much faster. Gimmetoo (talk) 02:09, 28 August 2012 (UTC)[reply]

Thank you, this is helpful too. So has anyone suggested an alternative way of writing/generating these templates that would work, but that wouldn't cause the slowdown? Or have there always been problems with the alternatives? SlimVirgin (talk) 20:30, 29 August 2012 (UTC)[reply]

Seeking your wisdom regarding talk templates

(By the way, you may want to increase the bottom margin on User talk:SlimVirgin/Editnotice by 5 or 10 points. It's being clipped by the subject/headline field when in "section=new" mode. —BigNate37(T))

Hi SV, I see that you were involved in the early stages of the BLP template, and you seem to have a lot of credibility and experience. Could you please spare a few moments to look at User:BigNate37/TM/Extant organization content notice, and perhaps share some wisdom with us on that template's talk page? A bit of a history lesson would be welcome guidance, especially in relation to what we're trying to do with the extant organization template. As much as I haven't seen any opposition to the organization template yet, I can't shake the feeling that editors are going to come out in opposition as soon as it sees some use. Thank you. BigNate37(T) 21:56, 27 August 2012 (UTC)[reply]

Thanks, Nathan, I'll take a look tomorrow. Thanks also for letting me know about the margin, which I think I've fixed. SlimVirgin (talk) 22:25, 27 August 2012 (UTC)[reply]
Thank you. And yes, the margins give your edit notice enough clearance now, even when the section/headline field is present. BigNate37(T) 23:20, 27 August 2012 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=User_talk:SlimVirgin&oldid=509959893"