Talk:Page Previews/2014/06

Hovercards provide you with a short summary of an article whenever you hover over a link to it.

Please give us feedback on your experience using this beta feature so we can change and improve it. You can read more about the feature here.

Archived discussion for this page are available at /Archive 1

Note: this page is using Flow; to give feedback on Flow, please use the Flow talk page

BUG - Dancing popup

When I hover over a link to another article the provided popup goes up and down and sometimes flashs too. Vicipaedianus X 10:27, 1 June 2014 (UTC)

Vicipaedianus x, Bob the Wikipedian, Ballofstring, Tuckertwo, Atomicbeachball, the patch is now live and tested. The core problem is fixed on all wikis. Thanks for your patience. :) Quiddity (WMF) (talk) 22:24, 5 June 2014 (UTC)

Apologies for the erratic behavior. There is a patch out for this and it should be fixed in the coming week. Vibhabamba (talk) 19:30, 1 June 2014 (UTC)

Unfortunately when this occurs you cannot navigate to that related article by clicking the link. Bob the Wikipedian (talk) 20:57, 1 June 2014 (UTC)

Yes this is a problem I'm been having too Ballofstring (talk) 01:04, 2 June 2014 (UTC)

mee too! tell me when it's fixed Tuckertwo (talk) 13:53, 3 June 2014 (UTC)

It should be fixed on Thursday (15:00–16:00 UTC). Quiddity (WMF) (talk) 04:15, 4 June 2014 (UTC)

I thought I was the only one with this problem. Thanks for the update. Atomicbeachball (talk) 16:40, 5 June 2014 (UTC)

This bug has been fixed and tested FF 12, Chrome, Safari.

Please re-enable the feature and let us know if everything looks good. Vibhabamba (talk) 21:39, 5 June 2014 (UTC)

Compatibility question

Sorry if someone's asked this before, I haven't looked at the Beta tab in a while. How does this work in tandem with w:Wikipedia:Tools/Navigation popups? I don't want to enable both and break something. Thanks in advance. Ansh666 (talk) 15:24, 1 June 2014 (UTC)

Ansh666: The following Gerrit patch - https://gerrit.wikimedia.org/r/120188 - automatically disables NavigationPopups if Hovercards are enabled but hasn't been merged yet. Prtksxna (talk) 00:06, 6 June 2014 (UTC)

@Prtksxna: Hmm, I'm sure we could do better than that.

I expect that automatically turning off navpop once you set Hovercards live for all users will annoy a lot of people, and lots of them will turn it off right away for that reason alone. Some will be annoyed either way of course, but this will provoke a lot more I think

To me personally, as an editor, navpop is most useful for getting quick access to a page's history and a user's contributions, and to look at diffs. Losing that would make me turn off Hovercards, even though I'd *love* to see navpop replaced by a sane and modern script eventually.

Two ideas:

• navpop detects Hovercards, and suppresses the navpop-popup on all links that will show a hovercard (not sure what those are, I assume all topic pages?)
  We should already do something with the reference popup I noticed …
• At the very least navpop can still make the flyout navpop-active so editors can still get all the actions, although with two steps now … are you exposing a hook when you show the hovercard, compareable to e.g. 'ext.echo.overlay.beforeShowingOverlay'?
  More advanced idea might be be to inject the action & status bar into the hovercard popup, but that would of course require somewhat heavier modifications …

In any case, site gadgets should arrange with MediaWiki & extensions, not the other way around. Amalthea (talk) 10:17, 9 June 2014 (UTC)

Hovercards is primarily for readers. It has large type and an article image so you can get quick context as to what this article is about. It doesn't carry the set of actions carried by Navigation popups which is mostly designed for editors.

Currently - you would have to manually turn navigation popups off in preferences > gadgets.

We are trying to fix this and will post a note when this is done. Vibhabamba (talk) 19:29, 1 June 2014 (UTC)

I love NavPop, it's my favorite gadget and one that usually elicits real joy in others (readers and editors alike) when they browse WP on my computer.

Have you considered adding options to Hovercards so that readers can customize it to be like NavPop, or like the current incarnation, as they wish?

In particular, the greatest simple pleasure of NavPop is its recursion, and the ability to directly follow a link in the hover-summary. Did you try a version that includes hyperlinks? Sj (talk) 18:11, 3 June 2014 (UTC)

Sj, Since Hovercards aren't replacing Navigation popups for now, users who like the advanced features of Navigation popups, such as recursive links, article metadata can continue to use Nav Popups instead of hovercards. Overall the feedback we've gotten has been positive about hovercards providing a single, simple target to the hovered article rather than displaying many targets to choose from.

We'd like to start very simple, and iterate from there, once we have agreement on moving forward with Hovercards in their current form as a reader facing feature we want to iterate on the design more as well as take some of the learning from Hovercards and apply them to Navigation Popups. Vibhabamba has been reaching out to community members to learn more about what are the make or break features they'd want to see in a refresh to Navigation popups, and we'll make sure to focus on if the deep-links/recursive nature of navigation popups is something that resonates with most users. Jaredzimmerman (WMF) (talk) 18:02, 6 June 2014 (UTC)

Jaredzimmerman (WMF):

I tried but didn't like Navigation Popups so turned them off way back but Hovercards are looking just great to me! I'm mainly an editor but also browse. I use Reference Tooltips and they seem to co-work just fine. Together they form a really good team, for me. I'm finding if the link is around halfway up the window the Hovercard can get truncated but this is a minor thing that seems to crop up in many types of dynamic web pages. I expect it is browser/OS related. I think I might prefer it if there was a slightly greater delay before the popup appeared but I expect I'm in a small minority. BTW: I'm not too familiar with Flow so I suppose my post is misplaced. Thincat (talk) 22:18, 6 June 2014 (UTC)

Thincat, eventually we'll be able to split this post into a new thread (soon, but not yet) the issue you're having with hovercards going off screen will be fixed soon. Glad you're enjoying using them. A lot of other users have mentioned that the amount of info on the old navigation popups we overwhelming and didn't help them quickly read and understand what a blue link was about at a glance, glad you feel that Hovercards do that. Jaredzimmerman (WMF) (talk) 02:33, 7 June 2014 (UTC)

Jaredzimmerman (WMF), User:Thincat, User:Vibhabamba : Good to hear!

I imagine only certain types of readers like the recursion, but those that do simply delight in it.

And now I have to try Hover+RefTips to see how they work together :)

I do like the clean hover design, though it makes me want to change font/image-size. Sj (talk) 20:45, 11 June 2014 (UTC)

Need an option to suppress the associated image

The associated image is frequently a poor choice for the first impression. The images are better suppressed if they do not help to convey the lede. But I do not see documentation for suppressing the image. Ancheta Wis (talk) 07:33, 7 June 2014 (UTC)

Ancheta Wis: Do you have specific examples ? —TheDJ (Not WMF) (talk • contribs) 19:45, 8 June 2014 (UTC)

TheDJ: This article has an indistinct illustration, which does not serve to illuminate the subject. It is better suppressed. Failing that, there needs to be an editorial process to allow only strong illustrations which better convey the lede idea in the hovercard. The opposite can be true as well. There needs to be an editorial process to present strong illustrations and omit weak ledes in the hovercards. Ancheta Wis (talk) 17:48, 9 June 2014 (UTC)

Ancheta Wis: Ehm, just edit the article ? I would disagree that this has much to do with Hovercards. Any article should have a strong lede to begin with of course. Hovercards just might make it a bit more visible that it is not. Remember that Google uses similar snippets in their search results (both image and text), so tweaking things specifically for Hovercards is not a good idea in my opinion. —TheDJ (Not WMF) (talk • contribs) 07:40, 10 June 2014 (UTC)

TheDJ: Yes, that is why I said "editorial process". We are building a system of which Hovercards are only a part. Ancheta Wis (talk) 14:27, 10 June 2014 (UTC)

On the face of it, navpop is a better tool than hovercards. Ancheta Wis (talk) 07:38, 7 June 2014 (UTC)

Ancheta Wis: I would say, it depends on your experience level with Wikipedia. —TheDJ (Not WMF) (talk • contribs) 19:49, 8 June 2014 (UTC)

TheDJ: Below I give an example of a subject which I study just for fun. I do not pretend to expertise. Navpop really helps me read without getting in the way of comprehension of an unfamiliar topic. Ancheta Wis (talk) 14:37, 10 June 2014 (UTC)

Ancheta Wis: Thanks for your feedback. What core functionality of nav-popups are you missing in hovercards? Are you an editor who uses the advanced action. If so, which ones? Vibhabamba (talk) 07:38, 9 June 2014 (UTC)

Vibhabamba: The popup is just better engineered. Here is an example article. When I hover over a link, the pop-up is a different color and its text is clearly different from the article. I read this as a supporting comment. But hovercards compete with the article, instead. Ancheta Wis (talk) 17:52, 9 June 2014 (UTC)

Ancheta Wis: I have already mentioned above about the need to suppress weak illustrations. Ancheta Wis (talk) 17:54, 9 June 2014 (UTC)

I see your point and you are right it does help. The color is being used to offset the popup from the content. We are trying to accomplish the same thing, but using a slightly different device. 3 different things offset the article content from the page. These are

1. Type size

2. Image and drop shadow.

With the new agora guidelines to create visual consistency across Wikimedia projects, we are a bit vary of using arbitrary orange and yellow hues for hovercards. Orange and yellow are being used to indicate warnings and such on discussion pages. They are also used for page templates. Hence avoiding that. Vibhabamba (talk) 18:42, 9 June 2014 (UTC)

Vibhabamba: When I see the popup I see violet letters on a salmon background with light gold trim. That said, I do not subscribe to the idea that overloading colors with meanings is a viable idea. Colors are a subjective mapping. I know that Green is currently being used in the Watchlist and you probably know that Green is not a good human factors choice. As another idea, have you thought of the Mac 'marching ants' marching around the border to denote a high urgency feedback indicator. Just an idea to show that colors need not be the only messaging device. The human eye is sensitive to other textures, like a leafy background, for example. The Roman generals used the 'laurelled dispatch' to express jubilation (Tacitus), etc., etc. Children tend to be sensitive to eyes, for example. I know that there are 25-year-old apps that look at you, on the Mac, ... ...

I am not trying to derail your freight train. That is why I first suggested above that the image is the weak point of the card and should be subservient to the text of the card. The navpop understands this.

As an example of the careful engineering of navpop:

here is an article I am studying. I move down to the 4th illustration, a coronal section of the brain. I hover the cursor over Brodmann Area 52, a new article, just 8 weeks old. The popup remains below the line of text I am reading, so I do not lose context.

The illustration of BA52 is inside the popup, and I

am able to see both the coronal section and a tiny image showing another aspect of the brain.

I am mentioning this to show that we have live examples and source code for good design before us, which should inform and guide subsequent development of newer tools

Here is a screenshot of a text, rather than an image Navigation Popup to illustrate. The caption

summarizes the points I illustrate as samples of the careful engineering:

Ancheta Wis (talk) 23:36, 9 June 2014 (UTC)

Hovercards stop working when mousing over a link for the second time

Steps to reproduce: 1. Open any Wikipedia article. 2. Mouse over an internal link. 3. Move the mouse off the link. 4. Put the mouse back onto the same link (or a different link with the same target).

Expected results: The hovercard should show again.

Actual results: I don't see a hovercard the second time; I just see the arrow, but no hovercard.

Workaround: Refresh the page.

Using Internet Explorer 11 on Windows 8.1 (though it also happens in Windows 7) Gparyani (talk) 16:25, 9 June 2014 (UTC)

Gparyani:

is this specific to some wiki, article and link, or is it everywhere? which browser (including OS and version) are you using?

i'm asking because i tried it, and for me it seems to work as expected: hovercard will show every time i hover over a link, no matter how many times i already viewed this card.

peace. קיפודנחש (talk) 16:44, 10 June 2014 (UTC)

קיפודנחש: If you read the whole thread, I am using IE11. I haven't tested it in other browsers. It happens everywhere. Gparyani (talk) 21:29, 10 June 2014 (UTC)

Gparyani: thanks.

seems to be an IE-specific bug. do you know if anyone opened a ticket in bugzilla?

please let me know, and if nobody did, i'll do it.

peace. קיפודנחש (talk) 16:26, 11 June 2014 (UTC)

קיפודנחש: I don't think so. Gparyani (talk) 16:44, 11 June 2014 (UTC)

Gparyani: please review Bugzilla:66496. if you have a bugzilla account you can comment there.

if you do not have an account, and want me to add more information to the bug report, you can do so here.

peace. קיפודנחש (talk) 19:49, 11 June 2014 (UTC)

The same result. It blocks second show of the card and over all it blocks link to go there. Idea seems very good, but this way is unacceptable. Tosek (talk) 16:57, 9 June 2014 (UTC)

Thanks for reporting this. Could you produce a gif and help us with fixing the bug for this? Vibhabamba (talk) 18:44, 9 June 2014 (UTC)

Vibhabamba: See the image link I gave below. Gparyani (talk) 16:12, 10 June 2014 (UTC)

User:Vibhabamba: I've produced it. The URL is http://gparyani.com/Wikipedia%20hovercard.gif

Oh, and I've added a workaround. Gparyani (talk) 21:12, 9 June 2014 (UTC)

So apparently there are some problems with IE 7 onwards. We are looking into it. Vibhabamba (talk) 22:18, 11 June 2014 (UTC)

How will hovercards work on touchscreens?

With the advent of Windows 8, touchscreen systems are becoming more commonplace. I propose that if a touchscreen is detected (i.e. with most browsers, by detecting the string "Touch" in the user agent string), that the first tap should show a hovercard, while the second should click on the link. If "Touch" is present in the UA string, but the user is using a mouse (you can detect that by seeing that the mouse cursor stays on the link for a while), the current default behavior should result. Gparyani (talk) 16:29, 9 June 2014 (UTC)

Excellent point, I think we might think of previews slightly differently on devices because of the layout flexibility they offer. We will of course reuse all the technical work that has been invested in building hovercards. Vibhabamba (talk) 21:41, 11 June 2014 (UTC)

What is the right delay?

Currently, the hovercard delay is 150ms. I saw many comments that indicated that this delay will (or should) be made longer, but did not find anything from the developers indicating that they agree, and did not see any discussion regarding the correct delay for displaying the card. i created Bugzilla:66301 asking for the delay to be increased to 500ms.

if you have any opinion on the question what should be the right delay (even if this opinion is that 150ms is best), or (better yet) you can point to some "industry standards" or "best practice" or "UI guru" that has some guidelines regarding the best delay, please add it either here, to bugzilla, or both.

peace. קיפודנחש (talk) 16:54, 10 June 2014 (UTC)

http://ux.stackexchange.com/a/360

And in MacOS X it is almost 1000ms apparently

http://www.componentix.com/blog/20/change-tooltip-display-delay-in-cocoa-application —TheDJ (Not WMF) (talk • contribs) 07:59, 11 June 2014 (UTC)

Make it customizable with two options: first "default", second "delay in miliseconds: ___" (min 0 max 9999) (9999 means deactivate) ⵓ (talk) 10:15, 15 August 2014 (UTC)

Note the default times were changed to 500ms (show) and 300ms (hide), a few weeks ago.

It is also customizable, using the user.js code (now located) at Extension:Popups#Show/hide timing. Quiddity (WMF) (talk) 01:25, 29 August 2014 (UTC)

Configurability

Please review the gadget "Reference tooltip" on enwiki. this tool has a small gear icon in the upper right corner of the tooltip, that opens a form with some very basic setup options (including "disable"). the settings are simple enough to be saved in a cookie. once disabled, there's a small linkette at the bottom of the page (i.e., part of #footer-places) to re-enable it.

i'd like hovercards to emulate this pattern - it's easy, intuitive, non-obtrusive, and once this will become default, easily available to anons.

for hovercards, some extra paramseters can be added, e.g. "font-size" (just provide rigid selection for 65%, 70%, 75%, 80%, 85%, 90% and 100%), and whether or not to show the image.

peace. קיפודנחש (talk) 17:34, 10 June 2014 (UTC)

We are looking into an easy way for readers to opt out of hovercards. Will post a link to this page once designs are finalized. Thanks. Vibhabamba (talk) 21:36, 11 June 2014 (UTC)

Vibhabamba:

opting out is only one thing.

other configurable options should include image suppression (as is apparent by many threads, here, many users do like hovercards, but would rather see them without images).

another one is font size: we (i.e., hewiki) used a hovercard-like gadget in hewiki since November 2013 (see he:Mediawiki:Gadget-showIntroOnHover.js, and the accompanying .css) and after much consulting with the community, we decided to use 75% for font-size. i think it will be good to let individual users to set it themselves through simple ui.

peace. קיפודנחש (talk) 22:34, 11 June 2014 (UTC)

קיפודנחש, thank you for the feedback, while we have gotten some feedback that users would prefer the hovercards without images, it has not been the majority, or really even a significant amount, we're trying to take all feedback into account and make choices that will benefit the most users while being an impediment for the fewest. We always have to make tough choices when it comes to a product and community as large as Wikipedia's. We know that very few users do a lot of interacting with Preferences, and are actively trying to simplify the site preferences with the help of community members. Unless absolutely necessary we avoid adding more items to the site preferences, relying on lightweight in-context preferences wherever possible. This is made further difficult for logged out users, we're reliant on rather fragile ways of saving preferences, cookies, localstorage, etc. We'd rather not create the expectation that the site is particularly customizable for logged out users and are being very careful with what items we allow there to be any user configurable options for.

Hope this make sense and helps you understand the kind of choices we have to make in situations like this. If you find that the Intro gadget on he.wiki is working better for you, it shouldn't pose a problem for you to disable navpopups and hovercards on your account and use the gadget you prefer for yourself instead. Jaredzimmerman (WMF) (talk) 00:33, 12 June 2014 (UTC)

Jaredzimmerman (WMF):

from your reply, it seems you either did not read or did not understand what i said.

nowhere did i suggest to add anything to site preferences.

i asked you to activate "Reference Tooltip" gadget on enwiki, and learn from the way User:Yair rand implemented configurability.

i specifically mentioned that this configuration is super simple, saved in a very short cookie, and is available to unregistered users.

please note that both "navpop" and "reference tooltip" provide an easy way for the user to suppress them. if hovercards won't follow this example, it will be much harder to convince communities to make it a default feature (and as can be learned from visual editor unfortunate advernture on enwiki, if the community decides something should not be on by default, it won't be on by default, regardless of how WMF feels about it). i'd rather see hovercards activated by default, so i'm asking you to provide an "off" switch.

Quote:

If you find that the Intro gadget on he.wiki is working better for you, it shouldn't pose a problem for you to disable navpopups and hovercards on your account and use the gadget you prefer for yourself instead.

your response indicate another misunderstanding: i created our "introonhover" before hovercards were introduced. if i've known at the time that this is in the works, i wouldn't have bothered.

i like hovercards much better than my hack. this said, it's still possible for you to learn something from my experience, no? it turns out, most users preferred smaller font for the tooltip.

having smaller font for tooltip may not be universal, but the fact is that my hack, "reference tooltip" on enwiki, and navpop all chose it should at least make you ask yourself if this has some merit. i suggest to at least let the user choose it herself.

to summarize: not wanting to teach unregistered users that wikipedia is configurable for anons is understandable. however, as much as i like this feature, it's undeniable that some users find it highly annoying. i predict that refusing to provide an easy to use "off" switch for unregistered users, will cause many wikis to refuse to activate this very nice feature as default. this will be unfortunate.

peace. קיפודנחש (talk) 16:27, 12 June 2014 (UTC)

קיפודנחש, I think i better understand what you're saying, thank you for clarifying (and noticing my misunderstanding) we are planning on having an easy "off" switch Vibhabamba will post the designs. It is modeled after the mechanism used by reference tooltips. Jaredzimmerman (WMF) (talk) 18:45, 12 June 2014 (UTC)

Settings to switch between Hovercards and Navigation Popups, or turn them both off.

https://www.mediawiki.org/wiki/Beta_Features/Hovercards#Settings

Also, updated on project page. Vibhabamba (talk) 00:07, 13 June 2014 (UTC)

Vibhabamba:

i like it, as long as we open a new form, i suggest offering 3 more configuration options:

• font size
• with images (or "hide image")
• hover delay (this can be dropped if you'll fix Bugzilla:66301)

as to "choosing between navpop and hovercard": as much as i like navpop functionality, its code is atrocious (or, at the very least, not very good by software engineering standards) and described by the people maintaining it as "unmaintainable".

i do not think WMF should assume responsibility

peace. קיפודנחש (talk) 12:15, 13 June 2014 (UTC)

Hovercards and Navigation Popups

Hi everyone,

We're rolling out an update to prevent Hovercards and Navigation Popups from both being active at the same time for any given user. This unintended interaction has been causing strange glitches and also a confusing user experience.

Once the patch is live, if you've opted in to both Hovercards and Navigation Popups simultaneously, then Navigation Popups will be disabled. Once you disable Hovercards, Navigation Popups will begin to work again.

This will only affect you if you're one of the few users that has both enabled. If you're using either Hovercards or Navigation Popups, or using neither, you'll see no change.

Thanks! Dan Garry, Wikimedia Foundation (talk) 00:05, 12 June 2014 (UTC)

When it's no longer beta, that would be fine. It was useful just now to determine which I like better to have them both enabled. Verdict: I like Nav Popups better. More information from the article, plus menus to do certain actions. Dismas (talk) 13:42, 8 July 2014 (UTC)

Dismas: Thanks for the feedback. If you prefer Navigation Popups, then definitely continue to use it! Hovercards is not intended to replace it, but instead intended to serve a different user group. Dan Garry, Wikimedia Foundation (talk) 17:34, 8 July 2014 (UTC)

I just became one of this group, just to help beta test things. However, because it disables Popups entirely I turned Hovercards to "Advanced" very quickly because, although I don't mind them when they do something, I don't want to lose the history link popup from Watchlists or User Contributions!

Oh and now I can't see how to change the "Advanced" setting if you ever change what happens, so definitely provide a link to display the settings somewhere other than on the Hovercard! Mark Hurd (talk) 05:31, 1 October 2014 (UTC)

alternative: html title attribute

Hi folks,

having the extracts in the hyperlink is pretty good. But for me it is too interfering when the hovercards pop up over my content. I use instead the HTML title Attribute and replace the existing lemma with the extract. Of course I have no image and metadata.

Is there a plan to get the extarcts als titles already from the renderd wikitext? ~ VanGore (talk) 09:59, 15 June 2014 (UTC)

VanGore: I very much doubt that. There is nothing wrong with having multiple tools for different types of users though. —TheDJ (Not WMF) (talk • contribs) 13:21, 15 June 2014 (UTC)

Love them

Just a brief note to say that I love these Hovercards, and to thank everyone involved in creating them. SarahSV ^(talk) 23:03, 17 June 2014 (UTC)

What view

I believe it would be better a "+ more" when we hover the link, and hover over this "more" then yes display the pop-up. Because otherwise the user may be reading the article and unwittingly pass the mouse over the link and then appear to pop up and take away your attention the article. Appearing directly to popup the user is very easy to see the pop-up unintentionally. Stanglavine (talk) 20:28, 20 June 2014 (UTC)

Topicon problem

When you have Hovercards enabled and you put your mouse over a topicon (protected page, quality article etc.) you can't see the text in the title=".." parameter.  Firilăcroco  ^Talk 12:13, 25 June 2014 (UTC)

thank you for reporting this, can you please include a screenshot? Vibhabamba (talk) 18:14, 25 June 2014 (UTC)

Vibhabamba: topicons on english wikipedia carry nopopups flag, allowing navigation popups to ignore these elements. Hovercards does not yet have that capability though.

With Hovercards, hovering this linked image does not show the above tooltip. —TheDJ (Not WMF) (talk • contribs) 06:46, 26 June 2014 (UTC)

Hovercards and compact personal bar

The stack order for hovercards and the compact personal bar looks broken on Chrome 35 / Mac OS 10.9.3.

DarTar (talk) 02:32, 30 June 2014 (UTC)

using the title is problematic. can't we use the real page linked?

an illustration: open [(astrology)] . notice the list of symbols at the bottom of the infobox. note that the hovercards are not what you'd expect them to be, b/c the "title" associated with the links are not what you'd expect, so many lead to disambiguation pages, while the images are linked to the correct pages. some are even more misguided: e.g., for the "cancer" image that links to "Cancer (astrology)", the hovercard is to "Cancer" and displays a frightening image of diseased tissues, instead of the astrology sign. this problem may be unique to images (is it?), but at least for those, we should not use the "title", and find a way to extract the actual link.

hint: this comes from template en:Template:Infobox zodiac, which contains images that look like so:

[[File:S can.gif|18px|link=Cancer (astrology)|Cancer]]

peace. קיפודנחש (talk) 23:20, 30 June 2014 (UTC)

Yes this is a known issue. —TheDJ (Not WMF) (talk • contribs) 16:53, 1 July 2014 (UTC)

TheDJ: "known" as in "there is a bugzilla ticket" ? do you happen to know the # ?

thanks,

peace. קיפודנחש (talk) 18:33, 2 July 2014 (UTC)

קיפודנחש: Now files as bugzilla:67466 —TheDJ (Not WMF) (talk • contribs) 09:22, 3 July 2014 (UTC)