Jump to content

User talk:Yair rand

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by קיפודנחש (talk | contribs) at 16:04, 18 October 2012 (→ResourceLoader and Reference tooltips: it comes from "wrong" method of testing for navpop.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Leave me a message. Unlike my main talk page on Wiktionary, this talk page does not use LiquidThreads. Thus, it will certainly take more than 10 seconds for me to respond to any posts made here. --Yair rand (talk)

Against Pending Changes

Add this userbox to your userpage to advertise your opposition to WP:Pending Changes, and tell 10 like-minded users to do the same and vote!--Gniniv (talk) 07:28, 1 September 2010 (UTC)[reply]
This user is against the implementation of flagged revisions in the form of pending changes.


join AUPS!

I saw your response to the current Pending changes/Straw poll and thought you might find it interesting to join the Anonymous User Protection Squad (AUPS)‎. Thanks, Maysara (talk) 02:43, 3 September 2010 (UTC)[reply]

Wikipedia:Pending changes/Straw poll on interim usage

Hi. As you recently commented in the straw poll regarding the ongoing usage and trial of Pending changes, this is to notify you that there is an interim straw poll with regard to keeping the tool switched on or switching it off while improvements are worked on and due for release on November 9, 2010. This new poll is only in regard to this issue and sets no precedent for any future usage. Your input on this issue is greatly appreciated. Off2riorob (talk) 23:54, 20 September 2010 (UTC)[reply]

Etymologies

Hi, I reverted your edits considering etymologies, per Wikipedia:WikiProject Etymology. A Macedonian, a Greek. (talk) 12:50, 14 December 2010 (UTC)[reply]

What? I don't see how Wikiproject Etymology somehow allows additions of etymology sections completely irrelevant to the topic of the article. Could you please explain? --Yair rand (talk) 21:50, 14 December 2010 (UTC)[reply]
I'm sorry but I don't understand... how can etymology of the article title be irrelevant to the topic of the article?? A Macedonian, a Greek. (talk) 21:58, 14 December 2010 (UTC)[reply]
The article title itself is irrelevant to the topic of the article. The article title is the English word that represents the topic of the article. On Wiktionary, pages deal with words, and thus give etymologies, pronunciation, etc. on those pages. On Wikipedia, articles deal with the actual concepts/things that the word represents. This distinction is pretty important. (On Wiktionary, my home project, the distinction is really important :). ) Furthermore, the etymology sections specifically dealt with the English word, ignoring all the other thousands of words in other languages that equally represent the concept, which is basically giving an English-speaking point of view. I know you've spent quite a lot of time on these etymologies, but they are really out of the scope of the articles and the project at large. Most of them should be simply deleted, and those that aren't redundant to Wiktionary's content should be transwikied. --Yair rand (talk) 22:06, 14 December 2010 (UTC)[reply]
On the contrary, Wikipedia:WikiProject Etymology states: The scope of this project includes articles about etymology itself and related topics (e.g. etymology, loanword), articles about the origins of particular words (e.g. List of U.S. state name etymologies, names of the Greeks), and etymology sections within articles on other topics (e.g. Ginkgo biloba#Etymology)... A Macedonian, a Greek. (talk) 22:19, 14 December 2010 (UTC)[reply]
Wikipedia:WikiProject Etymology is not policy. Certain articles may have a name or a word as their subject, or have information related to the name that is distinctly notable, and information about the words themselves could be in the article. Most articles are not about names or words. Leaving aside for a second the issue of whether information about words of languages that represent the relevant topic are closely related enough and notable to be included, I don't see how etymologies can be in articles. Assuming that the etymologies wouldn't put forward an Anglo-centric viewpoint by excluding any information related to non-English words that represent the subject of the article, the etymology simply wouldn't fit. After a few dozen languages, the section would be larger than the entire rest of the article, and would have to be split off into something like "Etymology of (subject)", which clearly isn't something that is needed on Wikipedia for every single word. In addition, there is no real benefit of duplicating massive amounts of Wiktionary content for every word that has an article on a project which doesn't have a lexicographic focus. Do you disagree with any of these points individually? Perhaps the issue should be taken to the Village Pump? --Yair rand (talk) 23:19, 14 December 2010 (UTC)[reply]
I think better to take it to Wikipedia:WikiProject Etymology talk-page and see the opinion of project's members. A Macedonian, a Greek. (talk) 07:38, 15 December 2010 (UTC)[reply]
Sure. Taken to Wikipedia talk:WikiProject Etymology#Etymologies not related to article subject. --Yair rand (talk) 06:28, 16 December 2010 (UTC)[reply]

Rv

Apologies, my fingers are too fat for my iPhone! I've reverted myself. Stephen 10:01, 31 January 2011 (UTC)[reply]

"Wiki"

With all due respect, I will refer to Wikipedia however I see fit depending on context. "Wiki" is as much acceptable shorthand as "US" for the country inbetween Canada and Mexico. doktorb wordsdeeds 19:04, 7 February 2011 (UTC)[reply]

IRC invitation

Because I have noticed you commenting at the current RfC regarding Pending Changes, I wanted to invite you to the IRC channel for pending changes. If you are not customarily logged into the IRC, use this link. This under used resource can allow real time discussion at this particularly timely venture of the trial known as Pending Changes. Even if nothing can come from debating points there, at least this invitation is delivered with the best of intentions and good faith expectations. Kind regards. My76Strat 08:45, 2 March 2011 (UTC)[reply]

Tab System

Hello, Yair rand. You have new messages at Jorm (WMF)'s talk page.
You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

Replied there.--Jorm (WMF) (talk) 01:28, 6 May 2011 (UTC)[reply]

interwikiwatchlist.js

Hello, Yair rand. You have new messages at User talk:Yair rand/interwikiwatchlist.js.
You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

--Timeshifter (talk) 10:53, 20 May 2011 (UTC)[reply]

Sticky notes

I really appreciate the thought behind the comment you made about the Sticky notes idea. Those are exactly the kind of issues I do not know enough to bring up! That is also the sort of stuff that would need to be discussed to get this idea ready for the proposal page of the idea lab. So, thanks for that.-Tesseract2(talk) 19:45, 27 July 2011 (UTC)[reply]

Nomination for deletion of Template:Wikisaurus

Template:Wikisaurus has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. The Evil IP address (talk) 10:56, 19 August 2011 (UTC)[reply]

Why did you remove the Handster Inc. acquisition section from Opera Software wikipage.

http://en.wikipedia.org/w/index.php?title=Opera_Software&diff=453842949&oldid=451487063

What sort of copyright violation was that? — Preceding unsigned comment added by Swapnil99pro (talk • contribs) 15:24, 27 October 2011 (UTC)[reply]

That text was copied directly from http://www.opera.com/press/releases/2011/09/19/ , which says at the bottom "Copyright © 2011 Opera Software ASA. All rights reserved.". --Yair rand (talk) 15:28, 27 October 2011 (UTC)[reply]

Reference Tooltips

Nice work on the Reference Tooltips script. I have one suggestion. It would be nice if the pop-up had a slight delay so that rapidly moving the cursor across a reference didn't trigger it. Kaldari (talk) 00:36, 7 December 2011 (UTC)[reply]

Oops sorry about the million milliseconds :) I was testing something and forgot to change it back. Kaldari (talk) 00:49, 7 December 2011 (UTC)[reply]
Regarding the namespace, I was just trying to cut down js bloat for other pages. I've added the Project namespace as well. Are references ever used in other namespaces besides those? Kaldari (talk) 00:52, 7 December 2011 (UTC)[reply]
In the Help namespace occasionally, I think. --Yair rand (talk) 00:55, 7 December 2011 (UTC)[reply]

Reference Tooltips 2

Is there any documentation on how to use it on another wiki? Is it the one used for example here --Spiros71 (talk) 21:58, 12 December 2011 (UTC)[reply]

No, it is not. By using it on another wiki, do you mean for one user to use it, or for it to be enabled for the entire wiki? If the former, one could just add importScriptURI("//en.wikipedia.org/w/index.php?title=User:Yair_rand/ReferenceTooltips.js&action=raw&ctype=text/javascript");importStylesheetURI("//en.wikipedia.org/w/index.php?action=raw&ctype=text/css&title=User%3AYair_rand%2FReferenceTooltips.css"); to their common.js on that wiki. --Yair rand (talk) 00:25, 13 December 2011 (UTC)[reply]

Hey, if you want help pushing this forward, let me know. It's of interest to us as part of our list of potential experiments here at the WMF (it might eventually be a good tool for prompting people take some kind of action to improve the reference). Steven Walling (WMF) • talk 22:29, 2 April 2012 (UTC)[reply]

removing political cartoons

Hey,

I've noticed that you have removed a number of political cartoons from articles relating to the Arab Spring, but I didn't see an explanation in the edit summary. So I'm writing here to ask you for the reason of removing them. (if this have been discussed, please redirect me to the discussion) Bahraini Activist Talk to me 09:51, 17 February 2012 (UTC)[reply]

I thought this was a pretty clear situation. Political cartoons, by their very nature, characterize events and issues in certain ways, and are thus non-neutral explanations of events. Wikipedia strives to provide a completely neutral point of view in articles. We can explain points of views in articles (X holds this view of these events, Y holds this view), but we can't have it as though the article itself has that view. Thus, there are only two ways that I can think of that would make the political cartoons acceptable to have in the article:
  • If the specific cartoon is a major element of the protest itself then the article could describe how it was used. It would probably be better to have a photo of it actually in use in that case, though. If that's not possible, then the caption should explain exactly how the cartoon was used, and how the cartoon is a notable element of the event.
  • If a section of the article describes certain views of the events, then it might make sense to include a well-known political cartoon in that section to help readers understand a certain popular viewpoint. In that case, the surrounding text should be also about views, and again, the caption should explain the cartoon and how it is relevant. (In this particular case, it would probably also be useful to get an image conveying an opposing viewpoint; perhaps a piece of government propaganda, if one is available, with surrounding text explaining how the event is being characterized by opposition to the protests.)
As far as I can tell, the political cartoons I removed did not fit either of these situations, and was displayed as though the cartoons were the article's representation of those events. Do you disagree with these points? If so, we should probably bring this to the article's talk page (if you disagree on how the cartoons were being used in the article) or perhaps a more general discussion page (if you disagree with the general principle that political cartoons are non-neutral representations of topics). --Yair rand (talk) 15:25, 19 February 2012 (UTC)[reply]
I just remembered about this just now. I guess I understand the reason for removing. But what about this cartoon? Also, some cartoons were used in protests, how would you suggest adding them? Mohamed CJ (talk) 04:50, 13 March 2012 (UTC)[reply]
For cartoons that were used in the protests, we could have photographs of people using the cartoons in protests. That would immediately supply the reader with much of the relevant information/context. (Sorry, I'm not completely sure what you're asking.) I'm not aware of how the cartoon File:Ali_Jawad_al-Sheikh_by_Ahmad_Nady.jpg is particularly significant, or what role it played, so I don't know about that. (There is an actual photograph of Ali Jawad al-Sheikh available.) --Yair rand (talk) 01:43, 14 March 2012 (UTC)[reply]

Reference tooltips bug

I love your reference tooltips script; however, I have noticed that when hovering over a reference a tooltip does not always appear. It seems to happen near the bottom of articles, so perhaps it's a bug in the code that detects whether the intended reference is already visible or not and decides whether to display a tooltip or highlight the existing ref? It might make sense to make a tooltip show even if the intended reference is visible. Thanks! —danhash (talk) 18:28, 4 April 2012 (UTC)[reply]

When the reference footnote is already visible on the screen, it's supposed to just add a border around the footnote. Is this not working correctly? --Yair rand (talk) 18:32, 4 April 2012 (UTC)[reply]
No. What I suspect is happening is that there's a bug in the footnote detection code and that the border is being added around the footnote but I can't see it since it isn't on the screen. My window is often not maximized, if that makes a difference. —danhash (talk) 18:46, 4 April 2012 (UTC)[reply]
Is it fixed now? --Yair rand (talk) 19:02, 4 April 2012 (UTC)[reply]
Yes. Thank you! —danhash (talk) 19:13, 4 April 2012 (UTC)[reply]
Great. Thank you for telling me about the bug. :) --Yair rand (talk) 19:16, 4 April 2012 (UTC)[reply]

Popups

Shalom. I'm wondering if you could have reference tooltips check for a variable set by popups, and if detected, disable itself. I'm assuming yours will get loaded after popups. If not, maybe the popups author could also insert code to check for a variable set in reference tooltips, and disable them if detected. What do you think? Equazcion (talk) 11:55, 19 Apr 2012 (UTC)

I added window.pg || to the beginning of the script, which should work, assuming that popups loads before Reference Tooltips. I still need to wait for an admin to synchronize the page in the Mediawiki namespace with the page in my userspace. --Yair rand (talk) 21:50, 19 April 2012 (UTC)[reply]

GMTA

so i just saw your reference tooltip tool. please compare with he:Mediawiki:Gadget-CiteTooltip.js. my tool use tipsy, which is a jquery extension to do tooltips. currently, tipsy lacks the syntax "please stay on while mouse hovers over tooltip", so it's a little bit more tricky to click a link in the reference. hopefully, sooner or later we'll take over tipsy, and then it's a very simple matter to add this syntax.

peace, קיפודנחש (talk) 21:03, 19 April 2012 (UTC)[reply]

added later: just saw the discussion in village pump, and these people are correct about the fact that gadget popup makes reftooltip redundant, and together they can be annoying. i suggest you add at the first line of the function show(), the following line or something similar:
if (mw.user.options.get('gadget-Navigation_popups')) return;
please note that if you want to handle it differently, e.g. to skip the initialization if popup is enabled, you can't just use this, because the "user" object is not guaranteed to be initialized as soon as the page loads. in this case, you want to add dependency in "mediawiki.user" to the gadget-definitions page.
peace - קיפודנחש (talk) 21:40, 19 April 2012 (UTC)[reply]
I added window.pg || to the beginning of the script, which should work, assuming that popups loads before Reference Tooltips. I still need to wait for an admin to synchronize the page in the Mediawiki namespace with the page in my userspace. --Yair rand (talk) 21:50, 19 April 2012 (UTC)[reply]
The code suggested above would seem to work whether or not popups loads first, so wouldn't that be better? Equazcion (talk) 22:06, 19 Apr 2012 (UTC)
Seems like a bit of a waste. The script would go through all the processes of attaching all the events and creating the tooltip whenever one hovers over a reference, and just not display them. I think (though I'm not completely sure about this) that gadgets are reliably loaded in the order they're listed in the gadgets list, so it's not really an issue. If this isn't correct, than yeah, I'll need to use קיפודנחש's method. --Yair rand (talk) 22:24, 19 April 2012 (UTC)[reply]
Couldn't you add if (mw.user.options.get('gadget-Navigation_popups')) to the very beginning of the script then, before any of that stuff is done? It just seems more reliable than assuming the script load order will stay the same, that's all. Equazcion (talk) 22:30, 19 Apr 2012 (UTC)
As קיפודנחש mentioned, the mw.user object is not guaranteed to be initialized as soon as the page loads, so no, not unless the script is specifically delayed to not run until after that point, which I'd rather not do. (Another option, by the way, would be to simply add .referencetooltips{display:none;} to MediaWiki:Gadget-navpop.css, popups' CSS file.) --Yair rand (talk) 22:40, 19 April 2012 (UTC)[reply]
I've requested this at Wikipedia_talk:Tools/Navigation_popups#Disable_a_conflicting_gadget. Equazcion (talk) 23:17, 19 Apr 2012 (UTC)

no, no, no - if you want to prevent initialization if navpop is used, you do not have to modify navpop itself - all is required is to edit Mediawiki:Gadgets-definition and change

  • ReferenceTooltips|ReferenceTooltips.js|ReferenceTooltips.css

to

  • ReferenceTooltips|[ResourceLoader|dependencies=mediawiki.user]|ReferenceTooltips.js|ReferenceTooltips.css

this way, it's guaranteed that the user object is ready by the time your code is run. this code does not care which gadget loads first - it just looks at the setup and sees whether or not popup is *configured* to run. personally, i wouldn't be so worried about "efficiency" as you seem to be. this code runs on the user's browser, not on the server, and normally it takes microseconds (or in the worst case miliseconds, if the user has a very old system) to complete, so IMO it should be good enough just to suppress the popups themselves, through the "show" function. if you are worried about performance, the real optimization would be to *generate* the content of the popup from within the "show", rather than creating all of them at load time (and it shouldn't be that difficult - again, look at my code in hewiki). peace - קיפודנחש (talk) 00:00, 20 April 2012 (UTC)[reply]

The content of the tooltip is not generated at load time, it's generated per-reference when the user hovers over the reference link the first time, just before show() is called. I suppose that the check for whether popups is loaded could occur on activation of the hover, though that would still have all the events attached to the reference links by that point (2 milliseconds or so of waste). (By the way, your estimates of the time it takes JS to create a bunch of DOM is off by a lot; the tooltip takes 2-5 milliseconds to create on Chrome on Windows 7 by my tests.) --Yair rand (talk) 00:28, 20 April 2012 (UTC)[reply]
you are correct, of course, but on the UI level, 5, 10 and even 150 milliseconds are not crucial. personally, unless performance is really atrocious, i go with code clarity and brevity every time. again, if you add the dependency on "mediawiki.user" in the MediaWiki:Gadgets-definition, you can then examine mw.user.options.get('gadget-Navigation_popups') at the very first line of your script, and the result is guaranteed to be correct. peace - קיפודנחש (talk) 16:09, 21 April 2012 (UTC)[reply]

Reference Tooltips 3

Sorry about that. The edit was an accident. I was testing code at User:Kaldari/ReferenceTooltips.js and accidentally edited the wrong page. My apologies. Kaldari (talk) 08:16, 26 April 2012 (UTC)[reply]

Regarding the delay feature in general, I've been using ReferenceTooltips ever since it was proposed as a gadget, and I think it is a much needed (and well-implemented) feature. The only problem I've had with it, is that I commonly accidentally mouse over a ref and then leave the cursor sitting in the resulting pop-up, thus obscuring the text. Your comment on my talk page suggests that you view the accidental triggering as a feature rather than a bug (i.e. otherwise newbies won't discover it), however, given the prominence of tooltips on the web these days (almost all of which are delayed) I think you might be surprised at how many newbies actually would try hovering over the refs. Perhaps a very short delay could be implemented such as 300 or 200 milliseconds. The Hebrew Wikipedia uses 300 for their reference tooltips. Kaldari (talk) 08:28, 26 April 2012 (UTC)[reply]
I suspect that many of our users aren't actually even familiar with the concept of "hovering" to get something at all. Not all that many of our readers are technically literate. Of those that are, I don't think many would try it. Given that the Reference Tooltips idea has never come up in discussion before afaik, I think it would be a reasonable assumption that even our core community never had the immediate idea "maybe hovering over these little links will do something?". Thus, if it doesn't get at some point accidentally activated, it's not going to be useful. It will probably result in a bit of annoyance for some users, but since it goes away as soon as one's cursor is no longer in that little spot, I think the annoyance will be very mild. (The accidental light flicker of reference content might actually be helpful even for users that know about the tool, if something there were to catch someone's eye resulting in them being suddenly interested in the reference, but that's a minor point.) So I suppose the accidental triggering is a mixed bug/feature, where the benefits of the feature outweigh the bug aspects enough that it makes sense to keep it, at least in my opinion. --Yair rand (talk) 08:47, 26 April 2012 (UTC)[reply]
A delay of 300 milliseconds isn't much, if any, of a "hover". It's less than a third of a second, and will "accidentally" happen anyway to those who don't realize the feature might exist. The delay would, though, allow those who are aware of it enough of a buffer to control when they see them. Thus I think the delay is a good idea, and might help gain a stronger consensus for implementation. Equazcion (talk) 14:05, 26 Apr 2012 (UTC)
FWIW, in hewiki we use a similar (homegrown) gadget that uses jquery.tipsy as backend to show the tooltips, and we *do* use 300 ms delayIn (as mentioned above, this is almost "industry standard" for tooltips). we also use "fade" for the tooltips. the way tipsy implements it is not 100% trivial, and you might be interested to scan the code if you want to get some ideas (you can't just start a timer naively - you want to verify at the end of the timeslice that the mouse is still above the control). you can read tipsy code to see how it does it here: https://github.com/jaz303/tipsy/blob/master/src/javascripts/jquery.tipsy.js
peace - קיפודנחש (talk) 23:18, 26 April 2012 (UTC)[reply]
Yes, delays on tooltip-style pop-ups are pretty standard, although there doesn't seem to be a standard for the delay time. Google Maps has a delay of about 200 milliseconds, while gMail is a full second. If referenceTooltips didn't have a hide delay, the show delay wouldn't be that important. But delaying hiding without delaying showing is especially annoying. Kaldari (talk) 22:30, 27 April 2012 (UTC)[reply]

Cite.php tooltips

Look like Cite has tooltips in development.[1] (Search for tooltips and popups). No clue if this works or when it would go live. ---— Gadget850 (Ed) talk 15:59, 4 May 2012 (UTC)[reply]

Talkback

You have new message/s Hello. You have a new message at Accedie's talk page. Accedietalk to me 22:51, 22 May 2012 (UTC)[reply]

ReferenceTooltips

Great work on improving ReferenceTooltips. It seems really solid now. I made a small code tweak to the test version to reduce the footprint a little and insure future compatibility with our jQuery UI skin: http://en.wikipedia.org/w/index.php?title=User%3AYair_rand%2FReferenceTooltips.js&diff=500739549&oldid=500406057

(The button() function is what normally adds all of those css classes and the internal span, so there's no need to do it manually.)

I'm not sure what's going on with Cite.php currently, but I'd still love to see this turned on by default (especially now that it has a configuration interface). Kaldari (talk) 02:47, 5 July 2012 (UTC)[reply]

I'm getting SyntaxErrors from that, so reverted for now. By the way, are you sure that jquery.ui.button is always available when jquery.ui.dialog has been loaded? (Or is it always available, maybe?) Is there a list of dependencies and defaults and such for these things anywhere? If ui.button can be depended upon, then the change makes sense.
Re RT on by default: I'm still much more in favor of it being community handled than having it as a non-community-editable extension. I'm hoping it will be enabled as a gadget soon. Relevant discussion: WP:VPM#ReferenceTooltips. --Yair rand (talk) 03:06, 5 July 2012 (UTC)[reply]
Ah, it was an extra ) that was the issue. --Yair rand (talk) 03:09, 5 July 2012 (UTC)[reply]
jquery.ui.button is always available (since about mediawiki 1.19 I think). Sorry for my sloppy coding :) You'll probably also want to do a blur() on the disable button at the end of openSettingsMenu(), since jQuery UI likes to activate the first dialog form element by default (which is usually OK since it's almost never a button). Kaldari (talk) 03:13, 5 July 2012 (UTC)[reply]
Blurring the button seems to kill tab navigation (or whatever that's called), so I'm leaving that out for now. I re-added your edit, minus the extra ). Thanks. :) --Yair rand (talk) 03:30, 5 July 2012 (UTC)[reply]
So is ReferenceTooltips getting enabled by default? David1217 What I've done 04:48, 6 July 2012 (UTC)[reply]
I guess that probably depends on the result of the discussion in VPM. Enabling a gadget by default can only be done by an admin, and I don't have admin rights on this wiki, and it probably wouldn't be appropriate for me to decide the result of a discussion I started anyway. --Yair rand (talk) 05:14, 6 July 2012 (UTC)[reply]

A barnstar for you!

The Technical Barnstar
For your fine work and persistence with Reference Tooltips, a great way to enhance Wikipedia for editors and readers alike. Steven Walling (WMF) • talk 01:37, 17 July 2012 (UTC)[reply]
Thanks! :) --Yair rand (talk) 01:44, 17 July 2012 (UTC)[reply]

The Wikipedia Adventure: Request for feedback on Community Fellowship proposal

Hi! I'm contacting you because you have participated or discussed The Wikipedia Adventure learning tutorial/game idea. I think you should know about a current Community Fellowship proposal to create the game with some Wikimedia Foundation support. Your feedback on the proposal would be very much appreciated. I should note that the feedback is for the proposal, not the proposer, and even if the Fellowship goes forward it might be undertaken by presently not-mentioned editors. Thanks again for your consideration.

Proposal: http://meta.wikimedia.org/wiki/Wikimedia_Fellowships/Project_Ideas/The_Wikipedia_Adventure

Cheers, User:Ocaasi 16:42, 27 July 2012 (UTC)[reply]

Reference bubble

Hello,

You may be interested in this discussion about the reference bubble.

Cheers,

--Nnemo (talk) 18:26, 6 August 2012 (UTC)[reply]

The problem that this user is reporting is that when a citation is near the top of a page, the tooltip isn't visible (it goes off the top). That is something that should be fixed, if you have time. David1217 What I've done 22:12, 8 August 2012 (UTC)[reply]
Not only the top of the page. My ref link was at the top of the view. Look at the screen photo. --Nnemo (talk) 07:14, 9 August 2012 (UTC)[reply]
Sorry for taking so long to get to this. I've been mostly without internet access for the past week.
So my personal opinion on this is that the tooltip should only be below the citation when otherwise there would be content that would be completely inaccessible, not when the user would just have to scroll up a bit to see it. I think general consistency of direction and clear visibility of content after the citation are more important than making it so the user doesn't have to scroll a bit to see the reference content. However, it looks like my view is the minority.
One complication in making the change: I'm not sure how often the script should check if all of the reference content is on-screen, to see if it should flip it. If a user is reading through a reference's content and scrolls enough that part of the reference is off-screen, it would be annoying if the tooltip instantly jerked out of the way so that it's below the citation, causing the reader to lose their place. I think it also wouldn't be best for it to check only once, and ignore whether it's entirely visible any later time. Maybe it should only check every time it goes from not visible at all to visible? --Yair rand (talk) 19:05, 9 August 2012 (UTC)[reply]
Don't be sorry. :-)
I had not thought about keeping part of the main text visible. The part that may be hidden by the ref bubble. But I think this point gives another good reason to my proposal. It is more important to keep the text before the ref link visible than the text after the ref link. So it is better to hatch the ref bubble downwards rather than upwards, even in the general case. Why ? We have this :
Some lines of text about apples. Bla bla bla bla bla. Apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples. Apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples apples. [1] Some lines of text about bananas. Bla bla bla bla bla. Bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas. Bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas bananas.
The ref [1] is about apples. So let's make it hide the bananas, not the apples.
This is the general case. But, if the ref bubble comes below the view, then put it in the view, so that the user does not have to scroll : in this special case, hatch the bubble upwards, or rightwards if there is room…
Having the bubble jumping here and there would be annoying. I think the best way to handle this is this one : as soon as you put the bubble on screen, don't move it.
Thank you !
--Nnemo (talk) 08:07, 10 August 2012 (UTC)[reply]
Okay, so I've made the change at User:Yair rand/ReferenceTooltips.js, but I'm going to hold off on requesting it be deployed across the whole site until I've done enough testing to be pretty sure the change didn't introduce any new bugs. If you'd like to participate in testing the modified version of ReferenceTooltips, you could disable the currently in use version by unchecking ReferenceTooltips at Special:Preferences#mw-prefsection-gadgets and then turn on the modified version by adding importScript("User:Yair rand/ReferenceTooltips.js");importStylesheet("User:Yair rand/ReferenceTooltips.css"); to Special:Mypage/common.js. --Yair rand (talk) 02:01, 13 August 2012 (UTC)[reply]
Thank you. One little thing to change : instead of writing "<br>" and "<hr>" : the correct forms are "<br/>" and "<hr/>". --Nnemo (talk) 10:09, 13 August 2012 (UTC)[reply]
Huh, I didn't know that $.fn.append actually built the DOM straight from the string. I figured it used the /^<(\w+)\s*\/?>(?:<\/\1>|)$/ regexp and then built simple elements through createElement, like jQuery does when one just puts $("<tag>"). I've changed the instances of "<br>" and "<hr>" to $("<br>") and $("<hr>") which, besides for fixing the invalid XHTML, will probably make it faster, I think. Thanks. --Yair rand (talk) 04:03, 14 August 2012 (UTC)[reply]

Simplified move proposal process

FYI. I have closed the discussion at Wikipedia:Village pump (proposals)#Simplified_move_proposal_process, noting near unanimous support for this proposal, but also possible need for further testing. --BrownHairedGirl (talk) • (contribs) 18:01, 18 September 2012 (UTC)[reply]

ResourceLoader and Reference tooltips

Hi, is there any reason why the tooltips are not loaded trough resourceloader ? I'm asking because currently this is a default gadget, and because it's not Resourceloader enabled in the gadgets definition, it requires an extra request for every user to the server. If added to resourceloader, it will be compacted into the same request as most of the other gadgets and user specific javascript. I think that would be beneficial. —TheDJ (talk • contribs) 14:59, 7 October 2012 (UTC)[reply]

ReferenceTooltips needs to be loaded after NavigationPopups if both gadgets are enabled in order to avoid conflicts, and NP is not loaded through ResourceLoader. I notice that HotCat, which is loaded through ResourceLoader, is loaded earlier than RT, despite being listed later in the gadget list, so I assume that if RT was loaded through RL, and NavPopups wasn't, then RT would be loaded before NavPopups, causing problems. --Yair rand (talk) 12:27, 14 October 2012 (UTC)[reply]
as an alternative to the way you do it now (testing for "window.pg"), you can test for mw.user.options.get('gadget-Navigation_popups'). this will require adding a dependency in gadgets-definition (mediawiki.user), but once you do add the dependency and change the testing for navpop, you can use resourceloader.
theoretically this will mess up users who load navpop not through the gadgets mechanism (e.g., directly through their common.js or something), but in practice you should not be concerned about these cases.
if you choose to do it this way, remember to add this dependency as a comment.
peace - קיפודנחש (talk)

Thanks for the reply

Thanks for replying at User talk:Yair rand/ReferenceTooltips. I have no experience filing bug reports at Bugzilla, but I'd be happy to file one if that's what it takes. I'm not sure I would file it correctly though. The issue at village pump technical isn't getting much discussion.[2] And in June, I submitted a comment, which was escalated to a Bugzilla report, and for months has gone unresolved. Perhaps that is on purpose. The last comment on Bugzilla was made in September. Is sort of thing common? Is it WMF responsibility to make bug fixes? Sorry to unload on you with questions, but I'm trying to figure this place out a little bit. Thanks. Biosthmors (talk) 17:55, 15 October 2012 (UTC)[reply]

It should probably be filed under Mediawiki extensions > MobileFrontend. It is, unfortunately, rather common for bugs to go unresolved for months or even years. The WMF can only afford to hire so many developers, and the volunteer developer community isn't generally able to handle everything that comes in either. However, I think something as severe as the mobile site actually crashing every time an Android user clicks on a citation is likely to be dealt with much faster than the average bug. --Yair rand (talk) 20:36, 15 October 2012 (UTC)[reply]
Interesting. Could you perhaps link me to some relevant commentary/analysis on WMF funding and where people think it should go in relation to this development backlog? Thanks. Biosthmors (talk) 22:56, 15 October 2012 (UTC)[reply]
Sorry, I have no idea where I would find stuff on that topic. Maybe on Meta. --Yair rand (talk) 23:08, 15 October 2012 (UTC)[reply]
No problem, and thanks again. Happy editing. Biosthmors (talk) 23:19, 15 October 2012 (UTC)[reply]

PostEdit

The labs instance we're using is http://piramido.wmflabs.org/wiki/Main_Page (you have to use the full url). Steven Walling (WMF) • talk 22:49, 17 October 2012 (UTC)[reply]

Thank you. I've posted the user CSS to hide the edit confirmation message on the VPT. --Yair rand (talk) 22:57, 17 October 2012 (UTC)[reply]
I can't get that CSS to work at piramido. (See RecentChanges for my stab at it.) Steven Walling (WMF) • talk 23:09, 17 October 2012 (UTC)[reply]
Okay, I just registered an account over there to figure out the problem. That Labs instance simply isn't loading any user styling at all. Try putting #mw-content-text::before{content:'The CSS was loaded'} in your CSS. Nothing. The source shows complete absence of the normal modules=user link element that's normally in the head. The CSS code I gave will work perfectly here on enwiki, there's just a bug in the Labs wiki. --Yair rand (talk) 00:01, 18 October 2012 (UTC)[reply]
Facepalm Facepalm I knew we should have checked that. Good news then. I'll update the VPT thread accordingly. Steven Walling (WMF) • talk 04:42, 18 October 2012 (UTC)[reply]
If only there were a production-ish configuration for a single MediaWiki test instance instead of copying & pasting out of 14,000(!) lines of cluster setup. Anyway, I changed piramido config to $wgAllowUserJs = true. Yair rand's CSS seemed to work for me, thanks! (I also added Extension:Vector for other preferences.) -- S Page (WMF) (talk) 08:42, 18 October 2012 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=User_talk:Yair_rand&oldid=518533930"