MediaWiki talk:Gadget-ImageAnnotator.js/Archive01

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Beta testers needed

This new script is intended to replace the existing ImageBoxes gadget, which apparently never worked right. Also, the annotations of this new script are not limited to single category names: they may contain arbitrary WikiText.

I'm looking for beta testers for this script. I have tested this rather extensively on the browsers marked as "OK" in the documentation, but I'll need your help to test it on browsers I don't have. Given the large number of browser idiosyncrasies (and idiocies) I've run into in my own tests, it is indeed possible that the script may not work as expected on browsers I didn't test. In particular, I need testers for Internet Explorer 7 and IE8. Tests for older browsers (IE 5.5, IE 5, FF1.5) are welcome, too, but expect errors (maybe we'll have to modify the script a little to only allow viewing of notes on such old browsers). Note that apparently even the monobook skin itself is broken on old IEs: [1]. Tests on newer non-IE browsers are fine, too (e.g. Firefox 3.5 beta), but frankly said, I don't expect any problems there.

Testing should exercise as many functions of the script as possible:

  • display/hiding of note rectangles
    • appearance of the note popups
  • defining new notes
    • but then cancelling
    • following through, entering text and saving
    • with preview before saving
    • trying to draw small or large rectangles
  • editing notes
  • deleting notes
    • by clicking "Delete"
    • by saving an empty text
    • start editing, but then open the same page in another window, edit & save there normally, then try to save the note in the first window: you should get an "edit conflict" message.
  • visiting an image page with Ajax turned off (if your browser supports that at all)

If you normally use some skin other than monobook, all the better!

If errors do occur, please include in your report what browser and skin you were using (including browser version), what operating system you're using, when (UTC time) the error occurred, your interface language setting, the error symptoms, what you did, whether the error is reproducible, what other gadgets you have enabled, and if your browser has an error console, whether there were any error messages there (and if so, what they said).

Please also report back if the script worked well in your tests.

Otherwise: just enjoy! Lupo 2009-06-17

First experiences

I did not do a formal testing yet, but used the gadget on File:A. Nevsky Cathedral in Warsaw (Aerial).jpg using Firefox 3.0.1. It worked great! Some minor issues I noticed:
  • one can not tell apart links to wiki pages from external links the little "arrow" . does not show.
  • Overlapping boxes can cause some boxes to be impossible to access. May be there should be a way to change order of boxes after their creation.
I will take closer look soon. Thanks for a great tool. --Jarekt (talk) 01:38, 18 June 2009 (UTC)
Unfortunately, both of these would be rather difficult to fix.
  1. Ext link formatting: this should be fixed in MediaWiki:Monobook.css and other global stylesheets. Fact is that most external link styling applies only to links contained within the content pane (in monobook, a div with the ID bodyContent). The tooltips used to display the notes, however, are globally positioned: in terms of the HTML structure (DOM), they are direct children of the <body> element. Hence they don't get styling that is specific to #bodyContent only. If extlinks etc. should be styled in tooltips, one should add rules to the CSS that applies this styling generally, and then switches it off for the areas where it is not desired. Alternatively, I could easily adapt MediaWiki:Tooltips.js to make sure that they all have a CSS class tooltipContent, and then the existing style rules for bodyContent could be made apply also within tooltipContent. But that's also a modification of the global skin stylesheets. Until now, I hadn't done that because I wanted tooltips to be completely independent of any of our style sheets.
    Technical note: the tooltips are appended to the body to ensure that they can be correctly positioned. Positioning of tooltips is global and in absolute coordinates, so it must be ensured that they are not structurally whithin some <div> with "position:relative" set, otherwise, they'd be positioned relative to that div, with the result that they'd appear in the wrong places.
    In fact, I've gone ahead and implemeted that tooltipContent class. For monobook, the styling could be corrected now by making all "#bodyContent a.external" and "#bodyContent a.extiw" rules also apply to class .tooltipContent by replacing the CSS selectors following the scheme
    "#bodyContent a.external" → "#bodyContent a.external, .tooltipContent a.external"
    Note that something similar should be done for all skins. Lupo 07:32, 18 June 2009 (UTC)
  2. Overlapping boxes: tooltips are not ordered among themselves (by zIndex or otherwise). AFAIK, Flickr's photo notes have the same behaviour: if you define a note covering the whole image, this makes all previously defined notes inaccessibly. I am surprised that this should be a problem, though. I would have thought it was a problem only if one note's rectangle completely covered another note's rectangle. Partial overlaps should not make any note inaccessible. For the time being, you can fix this by editing the image description page manually such that the "covering" note appears textually before the "covered" notes, like I just did on File:A. Nevsky Cathedral in Warsaw (Aerial).jpg. I'll think about whether the script could check for that automatically and insert such "covering" notes in the right place automatically instead of just appending them. But even that would be only a partial solution: a note could still become inaccessible if its rectangle was completely covered by several other boxes, without being completely covered by any of them. But maybe that should be considered a pathological case that indeed should be left to manual correction. (It's exactly the case with the note order I fixed on that Nevsky Cathedral photo.)
Lupo 07:11, 18 June 2009 (UTC)
I also noticed on File:A. Nevsky Cathedral in Warsaw (Aerial).jpg, which is densely crowded with rectangles, that it became difficult to tell (a) where there were boxes, and where there was empty space between boxes, and (b) when a popup appeared, to tell to which box it belonged. I've tried to solve the first by giving each rectangle a structured border: yellow on the inside, gray on the outside, and the second by highlighting the box a popup belongs to. You should force a reload now to get these changes. Lupo 13:42, 18 June 2009 (UTC)

I think we should have a template automatically inserted above the {{Information}} which would inform users that they should turn on the gadget in order to see file annotations. Unless of course the gadget will be ON by default. --Jarekt (talk) 18:49, 20 June 2009 (UTC)

And then have the script suppress the display of that note if it is active? Indeed, good idea if we're not enabling this for everyone. But actually I think we should enable it for everyone (by just importing it in MediaWiki:Common.js; unfortunately, there's no other way to have gadgets be switched on by default—IIRC, there once was that option in the Gadgets extension, but it got turned off) once we've tested it well enough and 30 days since the last modification to MediaWiki:Tooltips.js have passed (that is, after 2009-07-19) , if we can show that it works on the large majority of all browsers. Looks good so far; I only need verification of Internet Explorer 7 (and 8, if anyone feels inclined to test there). On all other reasonably current browsers it works. I don't have really old browsers around to test against (IE5.5, FF1.5), and on even older browsers (IE5.01, IE4) even the monobook skin itself is broken (see e.g. [2]), so I guess we may ignore those. I do wonder about Konqueror 3.5.7, though... (I don't have that, and can't run it anyway.)
Of course enabling it for everyone by default would be best. Otherwise, this remains a niche functionality for logged-in users who happen to have the gadget activated. Lupo 20:38, 20 June 2009 (UTC)
Looking at these statistics, I think we could risk enabling in for everybody if we have positive tests for Internet Explorer 7 and 8. If anyone wants to try Firefox 3.5, that'd be great, too, but I don't expect any problems there. I'm more worried about these M$ contraptions. Lupo 22:50, 20 June 2009 (UTC)
I like it ON by default too. Should we have an maintenance auto-category category:Images with annotations for all images using this gadget? --Jarekt (talk) 13:41, 21 June 2009 (UTC)
I can not get the gadget to show up on File:Bundesarchiv Bild 183-41001-0032w, Berlin, Neue Wilhelmstraße (Zeichnung).jpg or any other Category:Images from the German Federal Archive file. I use Firefox 3.0.1 --Jarekt (talk) 02:23, 22 June 2009 (UTC)
Fixed. Don't forget to reload your browser's cache before re-trying. Lupo 08:31, 22 June 2009 (UTC)
Would it be OK to add <includeonly>[[category:Images with annotations]]</includeonly> to {{ImageNote}}? --Jarekt (talk) 15:16, 22 June 2009 (UTC)
You may do that. It should not cause any problems for the script. Lupo 15:33, 22 June 2009 (UTC)
I can not - It is protected. May be you can edit or semi-protect until it become widely used. --Jarekt (talk) 16:00, 22 June 2009 (UTC)
Oh, sorry. I thought you were an admin... Ok, I'll add the category. Lupo 06:49, 23 June 2009 (UTC)

Adding Error checking

I added error checking to {{Location}} template family which checks for several error types and populates Category:Media with erroneous locations which I routinely monitor and correct. Similar thing might be added to {{ImageNote}} to catch bad hand-changed parameters and image reuploaded with different size and automatically add Category:Images with erroneous annotations.

  • add check for ImageNote box bigger than image size (to catch people doing bad hand adjustments to the code}}
  • if possible pass to the ImageNote current preview size and flag images where current preview is different from original preview size.
  • there might be other problems to look for

--Jarekt (talk) 16:00, 22 June 2009 (UTC)

  • The script currently silently ignores any notes where dimx, dimy ≠ size of the full image. I could make it issue some warning text if it finds non-matching notes (or duplicate note ids)...
  • The script and {{ImageNote}} are independent of the preview size. All coordinates in the template are relative to the full image size and are mapped on the fly to the current preview size, which depends on the user's preferences. There is no "original" preview size.
Lupo 06:48, 23 June 2009 (UTC)

The obvious

I guess I'll ask the obvious since I don't see it anywhere on this page... vandalism and edit warring. This gadget seems wide open to it. Jokesters vandalizing images with wrong or inappropriate "tags". User warring over what something in an image is (that's my house! no it's not, it's mine!), etc. One such "ploy" has already been pointed out above.. someone running around covering the whole image with a "tag" thereby making any other tags within the image inaccessible. So what's the thoughts on this and dealing with this. - ALLST✰R▼echo wuz here @ 14:33, 25 June 2009 (UTC)

None at all. It's all normal edits to the image description page. Revert vandals like you'd do otherwise. Lupo 14:36, 25 June 2009 (UTC)
Such vandalism would be much easier to spot if the automatic edit summary included the content of the added/deleter/modified note. Pruneautalk 15:41, 25 June 2009 (UTC)
Good idea. ✓ Done I've also added some more stringent checks that the coordinates as recorded on the image description page actually make sense (are within the image bounds). To get these improvements, please reload your browser's cache. Lupo 17:15, 25 June 2009 (UTC)

uselang=eo

In an Esperanto UI the script works with small images, but not with big ones. E.g. look at File:PTS-Moscow Mitino 3mkr from fl22d40.jpeg with “?uselang=eo”. I guess it fails at the space which separates thousands in the image dimension numbers. --AVRS (talk) 17:07, 25 June 2009 (UTC)

Right, it never occurred to me that whitespace could be used as a thousands separator. I'll fix it right away. Lupo 17:19, 25 June 2009 (UTC)
✓ Done. Please reload your browser's cache. Lupo 17:42, 25 June 2009 (UTC)

List of notes

This is amazingly cool. Would it be possible to add a list of all notes below the image, such that when you hover or click on one note name, only the corresponding box is shown on the image? This would be similar to the tags in Facebook photo albums. Pruneautalk 11:06, 25 June 2009 (UTC)

Notes are not named... and since they may contain arbitrary WikiText, we can't take their content as the "name" either. I must admit I don't know Facebook at all, so I have no idea what their "tags" are. Lupo 11:17, 25 June 2009 (UTC)
Saw your e-mail. I see. Would not be exactly easy, we'd need to program a way to (optionally) associate a "tag" or "name" with a note... once that's done, it's then easy to display these names below the image. Input would need to be limited to simple text, I presume.
I'd like to have more input on such a feature. What do others think about this? In the UI, I'd add a single-line input to the note editor. Input would be treated as simple text. (Hmmm... that would mean I'd have to encode all [, {, ], }, |, <, > characters inside. Anything else?) The {{ImageNote}} template would get a new parameter "tag" with that value. Tags, if there are any present, would be displayed below the image in a line saying something like "Notes in this image:" followed by the tags. (There's a minor internationalization problem here: we should use the current value of MediaWiki:Comma-separator between tags, and what markup would work best for rtl languages?) Hovering over or clicking on a tag in that line would then show and highlight the rectangle. Who else would like to have that? Lupo 10:27, 26 June 2009 (UTC)

Annotation code

I looked at the annotation code a little closer. For example: 

<div id="image_annotation_note_1" class="image_annotation" style="display:none;">
  {{ImageNote|id=1|x=558|y=136|w=73|h=73|dimx=988|dimy=500}}
<div id="image_annotation_content_1">
[[w:Otto von Bismarck|Otto von Bismarck]]
</div>
<span id="image_annotation_wikitext_1" style="display:none;"><nowiki>%5B%5Bw%3AOtto%20von%20Bismarck%7COtto%20von%20Bismarck%5D%5D

</nowiki>

Would it make sense to hide most of the text above inside some template so the code looks like: 

{{ImageNote2|id=1|x=558|y=136|w=73|h=73|dimx=988|dimy=500|content=[[w:Otto von Bismarck|Otto von Bismarck]] |text=%5B%5Bw%3AOtto%20von%20Bismarck%7COtto%20von%20Bismarck%5D%5D}}

This might make pages less cluttered.

At least I would bracket it with <!-- Image Annotation Code: begin (do not modify) --> and <!-- Image Annotation Code: end -->. --Jarekt (talk) 19:12, 25 June 2009 (UTC)

Can you guarantee that arbitrarily complex wikitext for the content (including <nowiki>s, <gallery> tags, images, mismatched braces, further template calls, tables, direct (x)html tags, parser functions, and whatever) cannot break the template? Lupo 19:26, 25 June 2009 (UTC)
I have trouble imagining a situation where one would want to include a gallery in a note... If this is an issue, maybe you could use two templates - something along the lines of
{{ImageNoteTop|parameters}} text of note, with complex and [[buggy] content if needed {{ImageNoteBottom}}

(similar to the idea behind {{Delh}} and {{Delf}}). Sorry if this is stupid or not clear. Pruneautalk 21:57, 25 June 2009 (UTC)

Not stupid at all. That would indeed be a possiblity. We'd still need the urlencoded wikitext somewhere. See below. Lupo 06:05, 26 June 2009 (UTC)

problem

I made a test edit to see, whether the script supports multiple languages. It works on display, but it fails on edit. When I chose the edit link from the annotation, I only got the English string in the edit window and the template was stripped. That should be fixed. --Slomox (talk) 19:44, 25 June 2009 (UTC)

You didn't update the urlencoded WikiText. Sorry, that cannot be avoided. Even using Jarekt's {{ImageNote2}} idea above it cannot be avoided. One might think that one could just omit the "text" parameter in his version and have the template construct that itself using the {{urlencode}} parser function, but unfortunately that fails when the input contains <gallery> tags, <hiero> tags, or <nowiki>s (or any other pseudo-tag from an extension). Just enclosing the wikitext in <nowiki> doesn't work either, because the wikitext could contain itself <nowiki>s, and these cannot be nested. And the script does need the wikitext itself on the rendered page, otherwise it would have to make yet another call to the server to get that wikitext, which might become prohibitively expensive (for the servers). Lupo 19:54, 25 June 2009 (UTC)
BTW, if you had made your test edit through the gadget, you wouldn't even have noticed that because the gadget automatically also updates that hidden urlencoded wikitext. Lupo 20:01, 25 June 2009 (UTC)
You are right, it would have worked, if I had used the gadget for the edit. But I'm a noob to the gadget and it didn't occur to me, that this could matter. I guess, more people will learn it that way, if the gadget is rolled out. It's a bit unfortunate, that the text is stored twice. It forces editors to use the gadget instead of the normal edit page. But I too can't think of any solution how to get along with saving the text only once. Would it help, if urlencode would properly support tags? (It's a bug, if {{urlencode:<hiero>x</hiero>}} ends up as "", isn't it? Or is there a reason for this odd behaviour?) But of course mismatched parentheses/pipes and tables could still break the template. It's not impossible to catch those cases, but I guess, it's very, very hard. --Slomox (talk) 21:19, 25 June 2009 (UTC)
It's probably not a bug, but a result of the way the parser handles extensions and built-in magic words: some mismatch between parser phases. But then {{urlencode}} was intended to be used to construct URLs, not to encode arbitrary wikitext. But of course it'd help if {{urlencode}} could handle this properly.
If the duplication turn out to be a real problem (say, lots of people (or bots!) want to edit note texts directly), I can rewrite the gadget to do without the urlencoded wikitext and get it directly from the server, but—as I pointed out above—that will require an additional call to the server if the user's first modification to the notes is an edit of an existing note. (If the first action is creating a new note or deleting a note, the script gets the wikitext as part of getting the edit page in the background anyway.) Lupo 06:02, 26 June 2009 (UTC)
  • Anyway, what the heck. I've rewritten the script to work without using this urlencoded wikitext. It does now make an additional call to the server to get the wikitext, but that happens only once, and only if the first modifying action on the page is editing an existing note. If that brings the servers down when there are many people using this, let the WMF improve their servers. Please, everybody reload your browsers' caches. Lupo 08:53, 26 June 2009 (UTC)
    P.S.: The new version can read the old note format using the <div>s, but will write only the new format as proposed by Pruneau in the section above. Note that it is not possible to combine the two templates {{ImageNote}} and {{ImageNoteEnd}} into one: the script needs some unique marker in the wikitext indicating the end of a note. Otherwise, I'd have to implement a full-blown wikitext parser in Javascript to find the end of a note, and that's out of the question. Lupo 08:53, 26 June 2009 (UTC)

Support for Wikipedias

Would it be possible to adapt this gadget to Wikipedias? A lot of our images are viewed from Wikipedias with users never coming to Commons. We might end up with a lot of image descriptions in in Image Notes, and it should be accessible even to people not coming to Commons. --Jarekt (talk) 04:10, 28 June 2009 (UTC)

The display of the notes is no problem, but of course adding/editing/deleting notes would be allowed only for locally stored images. Lupo 08:44, 28 June 2009 (UTC)
Another thing is that the script should be tested then on rtl wikis. Might need some adaptations; the script uses sometimes fixed alignments, and it wraps the image in a <div style="float:left"> to make sure everything is still positioned correctly when the window size changes. That would probably have to be float=right for rtl wikis, but float=right triggers a multitude of layout bugs on Internet Explorer. Especially IE6 is incredibly broken on right floats. I fear that might take substantial testing and work-around hacks. Lupo 08:57, 28 June 2009 (UTC)
Surely this is also an issue on Commons, for users who have an rtl language interface? Pruneautalk 09:07, 28 June 2009 (UTC)
Of course you're right. Adapted it to also work on rtl wikis, including the Commons if wgUserLanguage is set to an RTL language. (Tested on ar-WP, and on the Commons using "uselang=he", on both FF 3.0.11 and IE6.) Apparently we're lucky, and our way of using floats does not trigger layout bugs on IE6. The test at ar-WP also verified that using the script there works as expected: it shows the notes, but doesn't allow to edit them (for files hosted at the Commons). I didn't test there with a local file: first, i don't expect any problems, and second, ar-WP is a totally strange environment for me; I won't hack around there. Lupo 09:21, 29 June 2009 (UTC)

Licence

According to the text displayed when adding a note, all notes are released under CC-BY-SA-3.0 and GFDL 1.2 and 1.3. All other text edits to Commons are also licensed under any later version of the GFDL; shouldn't it be the same for notes? Pruneautalk 09:44, 28 June 2009 (UTC)

Feel free to modify the text (but keep it short, and without fancy icons, please, otherwise that edit popup gets too large). It's configurable at MediaWiki:ImageAnnotatorCopyright and subpages thereof. Personally, I would not include the awfully long "or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. ... " and so on. I'd rather just add "See our terms of use for more details." to the text. Lupo 10:48, 28 June 2009 (UTC)

Naming of revert

I find odd the use of Revert on this gadget, since Reverting is something different on the wiki. What about renaming it to Discard?

There is also a bit of expectation of 'Cancel' to discard the changes. Not sure if it doesn't 'by design'. It's unintuitive. So if it is going to preserve your wikitext changes between 'edits', it might be better to name that 'Hide' instead.

Platonides (talk) 12:10, 1 July 2009 (UTC)

"Cancel" cancels modifying the note, but true, it does preserve the text as is unless you open another note for editing. It's easy enough to make it discard the changes in all cases. "Revert" struck me as a fitting term, as in "Revert my changes" or "Revert to the stored version". The corresponding terms in the other languages I checked correspond to these meanings. These buttons currently use already existing MediaWiki messages, but I could change the UI localization setup easily enough to make them configurable and use the MediaWiki default messages only if there are no localizations for the ImageAnnotator-specific messages. Lupo 12:25, 1 July 2009 (UTC)
In fact, button customizability is already ✓ Done now. See Help:Gadget-ImageAnnotator#User interface texts on how to override the default naming. Lupo 12:42, 1 July 2009 (UTC)
The problem is, I thought in it as "Revert the note". Reverting what others wrote, jsut as when on the wiki the revert action undoes the last edits by someone other. Starting the note with the Revert button disabled and enabling when the text changes could help. Platonides (talk) 13:59, 1 July 2009 (UTC)
Good idea, ✓ Done. You'll have to reload your browser's cache to get that change. (Or wait 30 days...) But reconfiguring the label is still also an option. Lupo 14:38, 1 July 2009 (UTC)

Category:Images with erroneous annotations

I still believe that images with annotations which were then reloaded, like this one should end up in Category:Images with erroneous annotations. --Jarekt (talk) 03:55, 4 July 2009 (UTC)

Any idea how this could be accomplished? AFAIK, there's no way to get the size of an image through some template or parser function magic... could be done in the script, but I daresay people wouldn't like it at all if the script automatically edited the page in the background to add that category if it detected a size mismatch. Lupo 07:25, 4 July 2009 (UTC)
So far I only worked with templates and with templates all you need is a condition which if met would add a category. I guess it is different when tool uses java scripts and with templates, I did not think enough about it when I proposed this. I guess one think that could be done is to create autocategorizing info-box template informing users that that Image Annotations on this page can not be displayed because image was re-uploded with different size and that one should either re-annotate or delete annotation code. This template could be added automatically by the script when this and other errors preventing display of annotations is detected. --Jarekt (talk) 19:54, 5 July 2009 (UTC)
Yes, in a template you just need a distinguishing condition. But how'd you write that condition, given that the template has no access to the image size of the currently displayed image?
Of course we could make the script display some such errors. But any such display would be temporary only, for the user currently viewing it. As I wrote above, I don't like the idea of the script automagically adding a permanent marker such as an error category automatically. Maybe display a message to the user together with a link "Include this file in Category:Images with erroneous annotations"? Then adding that category would only occur on explicit user interaction. Lupo 21:12, 5 July 2009 (UTC)
If user is active enough to click that, (s)he would be active enough to fix the problem without reminders. I was imagining this message for users that upload and abandon files. Kind of users that upload 400 files using nonexisting templates like Special:WhatLinksHere/Template:Coord and never look at resulting pages to notice it (I think I might clean up this lot soon). If you object to a error category we could only add an info template explaining what happen, than we can find problem files by checking where the template is used. --Jarekt (talk) 02:20, 6 July 2009 (UTC)
I don't object to an error category at all. But I don't think it's a good idea to make the script make automatic edits that are not the result of some user interaction. Lupo 06:48, 6 July 2009 (UTC)
May be script after detecting a problem can add image to a list in MediaWiki:Gadget-ImageAnnotator.js/Images with erroneous annotations or similar page? Also it could post a note at the uploader page. --Jarekt (talk) 20:06, 7 July 2009 (UTC)

Changes

There's now a zoom feature for large images (see the documentation. The zoom initially just displays the preview image upscaled by the browser, but it loads a truly larger image in the background and will show that once it has arrived. Since the WMF servers, and in particular the image servers, are rather slow currently, this may take some time, though.

Just a message for the beta-testers: if this script has stopped working for you, just reload you browser's cache. There have been some server-side changes, and I had to adapt the script accordingly. Lupo 15:10, 12 July 2009 (UTC)

I really like this new feature, but I do not like the zoom to be on while selecting the region. May be we can control it somehow like have a w:check box or on/off button to turn magnifying glass on and off. This feature could be useful by itself for users not annotating at the moment. Sorry, to always have dozen of "great ideas" that require code changes. ;) --Jarekt (talk) 14:03, 15 July 2009 (UTC)
Well, it's on only for really large images by default, and it's on when drawing a new rectangle on purpose, because that was the whole point of it: to be able to better position rectangles on images like e.g. File:Chicago.jpg. It doesn't make much sense to have the zoom disappear when you click (all the more since I tried hard to find some position where it'd be always out of the way—the current position is only then not optimal if you draw the rectangle (in an ltr-language-view) from the bottom right to the top left) since you'd also want to use it to set the second corner of the rectangle.
As a general zoom utility, this zoom is not good. You'd want something more elaborate, maybe with sliders like on Google maps for zooming, and you'd need server-side support to do it efficiently. And if it'd be done in-place, it would need to interface with this gadget to adjust rectangle sizes to the current zoom level.
Lupo 14:24, 15 July 2009 (UTC)

Making an edit mode

Currently for images like this http://commons.wikimedia.org/wiki/File:Chicago.jpg the edit button distracting. So how about an edit mode? Most of the viewers wouldn't edit the notes so how about differentiating between an edit mode and a viewing mode?--Diaa abdelmoneim (talk) 16:30, 15 July 2009 (UTC)

Why? These two links in the pop-up notes are so small... Most of the people who view a Wikipedia article don't edit it, but it still has an "edit" link. Also, anything that's modal complicates things. But if there's really a consensus for that, it could be done, of course. BTW, any interest in providing some Arabic translations? Lupo 16:39, 15 July 2009 (UTC)
I'd be interested to do the translations. No biggie about the edit button. However I was thinking many of the annotations contain a link to a wiki article so how about making a wiki icon floating for a related Wikipedia article? Just an idea, something like Google earth does.--Diaa abdelmoneim (talk) 16:59, 15 July 2009 (UTC)
That's an interesting idea. Hmmm... it's certainly easy to scan the HTML of a note for links going to ".wikipedia.org". But we'll have to think carefully about how to do this to avoid creating a mismatch between user interaction metaphors. If we'd display a small "W" icon in the upper right (or upper left for rtl languages?) corner, what should happen when the user clicks that (or moves the mouse over it)? Four options: nothing (not good), open the note, open the first wikipedia-link found (probably not so good, potential for confusing the user, especially if there are several wpikipedia-links in the note), or display the note if there are several links, but open the linked article if there's only one (probably just too confusing: context-dependent action, and the user doesn't even see the note at that moment). And what to do if things get crowded, for instance, when there are several boxes that have their upper right (or left) corner next to each other, close enough that the "W" icons would overlap? This would certainly need more thought... Lupo 16:11, 17 July 2009 (UTC)
Well I was thinking if there is only a Wikipedia link then there should only be the icon with an alt text with the name of the subject or more detailed info. The icon's link should be linking to the article that is on the same language of the preference of the user. If not available then it should link to the one available alphabetically. The icon could have an arrow down that shows the available language links. The Image Annotator has a lot of potential and I think with icons less boxes would disturb the user. An icon for similar image of or another side of a building for example would be great. I think this Gadget should in the near future become default on Commons and your efforts are really great.--Diaa abdelmoneim (talk) 11:41, 20 July 2009 (UTC)
I think this is getting too complicated, with too many special cases. "Other view" notes can be done by simply including a thumbnail in the note, see e.g. File:Spelterini Blüemlisalp.jpg for an—admittedly not very spectacular—example. The "link by default to the article corresponding to the user's language settings" would be very complicated to implement, if it could be done correctly at all (because article names vary across different languages). In any case, the various articles' names in all the languages would need to be present in the note. I think it'd be easier to just use {{LangSwitch}} inside a note to achieve nearly the same effect.
BTW, to translate the interface, see here for which messages are needed. Either place your texts at the talk pages of the /ar subpages and then notify me to copy them over to the protected MediaWiki namespace, or place them here. Lupo 12:04, 20 July 2009 (UTC)
Some of the links are red links. Are they for later or something? BTW, I can also translate to German, which I speak better than English. About the icons thingy. Ok, how about for example for "Gspaltenhorn" note, it would be replaced with a simple small wikipedia icon? Instead of the full fledged note?--Diaa abdelmoneim (talk) 12:26, 20 July 2009 (UTC)
The German, French, and Spanish texts are already done (Spanish might need double-checking; my Spanish isn't that good). But Arabic (or any other language) would be great. The first five messages are red links, but use existing MediaWiki messages for the default. We only need those if the defaults (for whatever reason) should not be appropriate. All the others except MediaWiki:Translate are needed. Lupo 12:44, 20 July 2009 (UTC)
Could u please list somewhere the already translated or partially translated languages? Something like the borwser compatibility...--Diaa abdelmoneim (talk) 15:11, 22 July 2009 (UTC) BTW it's very complicated to translate these messages. I can't edit the source, there is no place to submit translation, please create some kind of template to add translations.--Diaa abdelmoneim (talk) 15:18, 22 July 2009 (UTC)
Put "{{MediaWiki:ImageAnnotatorUITexts|lang=ar}}" in some edit box and hit preview. That shows you the not-yet-existing messages for the Arabic interface. For the time being, I have no translation system in place (like e.g. for the Upload form), but I'm planning to do one. Just place your translations at the talk pages of the messages; once done, I or another admin can move them into the MediaWiki namespace. Lupo 15:42, 22 July 2009 (UTC)
Translation links ✓ Done. Just go to e.g. an Arabic page, reload your browser's cache, and then click on the translation link. Lupo 08:38, 23 July 2009 (UTC)
Translation ✓ Done--Diaa abdelmoneim (talk) 13:03, 23 July 2009 (UTC)
Thanks! Please see my comments at MediaWiki talk:ImageAnnotatorTexts. Lupo 13:42, 23 July 2009 (UTC)

File:Ruins of Warsaw (1945) 4.jpg

I added 4 notes to the image above but only 2 show up. I noticed that 3 of the notes have the same id. --Jarekt (talk) 15:04, 21 July 2009 (UTC)

Hmmm. What exactly did you do? Can you reproduce this? (The display problem can be fixed by simply giving the notes different ids.) Lupo 15:54, 21 July 2009 (UTC)
As you can see in the history I added 3 notes in 3 minutes, using only GUI. I did not do anything different than many other times I used the tool. I noticed that after doing the first box the result did not did not showed up afterward. So I checked the source to make sure it made it there. Since I saw the code of the note I added 2 more notes without any of them showing up. Than I reloaded the page and one box showed up so I added another note (id=2). I successfully reproduced it as well: here in File:Climbing in Joshua Tree NP.jpg image, when I added 4 notes in one minute using GUI. Than I tried it on File:Gunks Traps - Rappelling - 1.jpg with page reloads in between and it worked fine. I am running Firefox 3.0.11. --Jarekt (talk) 17:21, 21 July 2009 (UTC)
I tried it again on a different machine running Firefox 3.0.1 - File:Indoor Climbing Kid.jpg with the same result. --Jarekt (talk) 02:34, 22 July 2009 (UTC)
That was fast. --Jarekt (talk) 12:35, 22 July 2009 (UTC)
Thanks. A bit stupid that I made this error in the first place. Anyway, how about translating the interface to Polish? Lupo 12:21, 23 July 2009 (UTC)

Icon instead of Rectangle

For maps like File:Transasia trade routes 1stC CE gr2.png the notes on the image would have a better style if it was an image icon like for example for Dura-Europos.--Diaa abdelmoneim (talk) 13:30, 23 July 2009 (UTC)

Preview not showing images over 200px

If u go to File:Transasia_trade_routes_1stC_CE_gr2.png edit a note and make the image 300px it doesn't give a preview. Ofcourse 300px is too large but some indication that it doesn't display that would be good.--Diaa abdelmoneim (talk) 13:33, 23 July 2009 (UTC)

Hm. That's actually a feature. If you had used the preview before saving the note, you'd have noticed. I don't know what other indication I could give. Maybe mention it in the help page. Lupo 13:40, 23 July 2009 (UTC)
And BTW, the limit is 299 pixels, not 200. Lupo 13:43, 23 July 2009 (UTC)

Bug report

I've done a quick test of the gadget, and it plays rather ok, though noticed a minor issue: If you are moving your mouse quick out of the image, the boxes remain. →AzaToth 14:10, 10 August 2009 (UTC)

For this to be useful you probably need to mention your browser type. --Jarekt (talk) 14:16, 10 August 2009 (UTC)
Happens sporadically on FF or Opera. IE has a couple of quirks, too (not showing notes promptly when the mouse enters a rectangle; it sometimes only shows them on the second or third try). It's all related to the rather inconsistent event handling in different browsers. IE sometimes forgets to fire events, or fires them on elements that should never even have gotten them. FF and Opera also sometimes forget to fire mouseout events, which is the immediate cause of the behavior AzaToth noticed. Since it's such a minor quirk, I'd prefer to treat this as a WONTFIX. Playing with the event handling code is a nightmare: if it works in one browser, it may well not work at all in another one. But I know that AzaToth is quite JS-savvy himself... if you can spot the source of the problem, we might still try to fix it for all browsers. Lupo 14:56, 10 August 2009 (UTC)

I think it's related to box boundaries. On FF 3.5.2, if I load this test image and move the mouse into the large bottom yellow rectangle and then out through the lower boundary of the image, the annotations remain highlighted most of the time. Not so if I leave the image through a path that doesn't contain any boxes -- and the closer a rectangle is to the edge, the more likely it appears that the event for disabling the annotations isn't triggered. Perhaps there's a way to have the event also trigger when the mouse specifically moves over the background area?--Eloquence (talk) 20:44, 10 August 2009 (UTC)

Hey, nice to see that even board members the WMF deputy director still have has the time to look at such mundane things going on on one of the projects!
You're right, it is a bounding box problem, combined with an event problem. I've got a fix ready in my working copy, but I want to test a little more to be sure it works on all browsers in my test set. As I expected, fixing this was non-trivial. I hope to have the fix to go live today, though. Will notify here when it does. Lupo 08:49, 11 August 2009 (UTC)
✓ Done, I think. Fix is live; if you refresh your browser's cache, note rectangles should now always disappear properly. Tested on IE6, IE8, FF3, Safari 4, Opera 9.26, 9.50, 9.63, Konqueror 4.2.3, and Chrome, all on Windows. (Don't have IE7 and FF2 right now, and I don't have a Linux machine.) People who already have used ImageAnnotator and hence have it cached in their browser will get the correction in 30 days unless they refresh their browser cache, but since this fix is cosmetic, not functional, I don't think this would be an impediment to enabling the script before these 30 days are up. Lupo 10:28, 11 August 2009 (UTC)
Hmm, now on File:WEF on the Middle East Arab and foreign Ministers.jpg, only the first box is shown, and it's not removed at all. I'm using Firefox 3.5 and firebox bugs with following error:
self.thumb is undefined
http://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-ImageAnnotator.js&action=raw&ctype=text/javascript
Line 1458

→AzaToth 14:02, 11 August 2009 (UTC)

Strange. FF 3.5 is right, of course, and it's fixed, but why didn't I get this error when testing? Probably I forgot to reload my cache... or FF3 erroneously accepts something it shouldn't, but FF3.5 flags it as an error. Could you please try again? Lupo 14:09, 11 August 2009 (UTC)
It works glitchless now :) →AzaToth 15:30, 11 August 2009 (UTC)


Ok, now when we are into the box issue, a similar issue when creating boxes exists. If while creating an box, drags outside the image and releases left mouse button, the box is still in the "red" state, and will still be moved when moving the mouse inside the image. I think it should trigger on mouse-release outside the image as well. →AzaToth 15:49, 11 August 2009 (UTC)

Actually, that was a conscious design decision. I tried both, and personally, I found it much more convenient if it didn't trigger outside the image. It gives a little less modal feeling: you can start drawing the rectangle, then leave the image, click links (open in new tab, presumably), do other things, and return later to continue drawing the rectangle, terminating just with a click. Lupo 18:11, 11 August 2009 (UTC)

Three (minor) changes

None of these should affect the basic functionality. All have been tested in IE6, FF3, Safari, Opera 9.5, Konqueror 4.2.3, Chrome on Windows.

  1. Note rectangles are now always sorted by size (width * height), in descending order. This makes sure that a new note that would completely cover existing notes is always placed "below" the existing notes, and thus all notes remain accessible at all times. Previously, it was possible to make existing notes inaccessible by placing a new note covering them. Note that there can still be cases where a (large) note is completely covered by several smaller notes and thus may become inaccessible. If anyone has a suggestion how to resolve this problem in general in a simple and efficient way, I'm listening. See also Help talk:Gadget-ImageAnnotator.
  2. The wikitext of new notes is inserted into the page right after the last wikitext of already existing notes (if there are any). Previously, the wikitext of new notes was always appended at the end of the page. If there are no existing notes (i.e., the new note is the first one), its wikitext is still just appended to the page.
  3. There's now a guard to escape occurrences of {{ImageNote}} or {{ImageNoteEnd}} within the wikitext of a note itself, as that might confuse note loading and sometimes make note contents seemingly disappear.

Lupo 21:07, 12 August 2009 (UTC)

SVG support

ImageAnnotator does not appear to activate for SVG files. See my attempt at File:Spectre visible light.svg (diff). Is this intentional? If so could Help:Gadget-ImageAnnotator list the image files it works for (PNG, JPG and JPEG I guess)? I tested it with Firefox 3.52 (logged in) and Opera 9.63 (logged in and out) on Windows Vista. Gadgets enabled: old-style upload form layout; Choose Resolution; UTCLiveClock; Change the "+comment" tab text to "+"; Gallery Details:; Add Information:; MyLangNotify. I then retested with all gadgets disabled, same result. Skin is Monobook, no error messages displayed and no errors in the Firefox error console. 84user (talk) 22:42, 12 August 2009 (UTC)

I'll update the help page. It's enabled on png, jp[e]g, and gif files. Don't remember why I hadn't enabled it on svg files. Off-hand, I don't see any reason not to enable it for svgs, too. I'll test a bit and if it works, I'll switch it on. Lupo 05:57, 13 August 2009 (UTC)
✓ Done. Enabled it for SVGs, too. You'll need to reload your browser's cache to have it work on SVGs. Lupo 06:27, 13 August 2009 (UTC)
Thank you, it works with SVGs for me too now. 84user (talk) 21:55, 13 August 2009 (UTC)

Migrate to Wikipedia?

Would this script port as-is to Wikipedia? Steven Walling (talk) 20:40, 14 August 2009 (UTC)

Not yet. Please wait. Some preliminary instructions on how to do this are at the help page, but please don't do it yet. Let it be used here first for a few weeks, and give me a chance to really do a port myself so I can make sure the instructions are correct. Lupo 13:55, 15 August 2009 (UTC)
Yes once it is used a little more widely. As of today we have 173 images using it, most of them probably not used on en wiki. --Jarekt (talk) 19:00, 15 August 2009 (UTC)
I wasn't thinking of creating a public page for it on Wikipedia, just using it personally. Steven Walling (talk) 01:49, 16 August 2009 (UTC)

Recent changes

Is there a way to display recent uses of this gadget? For example, the hidden Category:Images with annotations is growing, so is there a way to list recent additions? I see Special:AbuseLog is listing several image note edits that have triggered the filter (I suspect many of them are due to an oversensitive filter), but are there amy more ways to monitor this? 84user (talk) 17:00, 18 August 2009 (UTC)

One answer to my question is to add "image annotations" to the Tag filter field in Special:RecentChanges, for example this shows RecentChanges for image annotaion in the File namespace. 84user (talk) 17:14, 18 August 2009 (UTC)

The filter is not oversensitive: it is designed to catch all edits made through this gadget. While it's not abuse, we have no way to log matches for this filter anywhere else. A bit unfortunate, but hony soit qui mal y pense. Lupo 17:16, 18 August 2009 (UTC)
There is a lot of unsuccessful experimenting going on: see File:Hockey.svg, File:House logo new.jpg, File:Emma Watson GoF Premiere 3.jpg or File:Jimmy Wales Fundraiser Appeal.JPG. Some of it should be deleted and we might need standards of use. --Jarekt (talk) 19:18, 18 August 2009 (UTC)

Enabled globally

See COM:VP#ImageAnnotator enabled. Lupo 09:02, 18 August 2009 (UTC)

Announcements and discussions in other languages: French; German, eingeschaltet. -84user (talk) 18:30, 20 August 2009 (UTC)

Feature request: enable on old revisions

Would it be possible to activate the gadget on old revisions of a page? There will be cases where notes have been removed, but one wants to see which notes used to be there. Pruneautalk 18:19, 20 August 2009 (UTC)

Queries

  1. - is it possible to edit the size of a box without changing the text? I found one annotated image (File:Mt.Ainodake from Happonba 03.jpg) where the box is so small it is hard to find; it could do with enlarging a bit.
  2. - what hopes for adding boxes that are not rectangular? I would really like to have had a triangular one to indicate the plants on File:Jastrabia veža from dolina Zeleného plesa.jpg.
MPF (talk) 20:02, 18 August 2009 (UTC)
Found out how to edit the box size (by trial and error!) - MPF (talk) 20:41, 18 August 2009 (UTC)
Support for (1) could be added. I'll think about how to do this best, but don't hold your breath. (2) is not possible as far as I am aware of. (Or if it is, not in Javascript or only with considerable difficulty.) Lupo 21:36, 18 August 2009 (UTC)
Thanks! One other I have thought of - if editing or deleting a note, there is no way of giving a reason for the change; it would be nice to be able to do so. - MPF (talk) 22:16, 18 August 2009 (UTC)
That would be a somewhat larger change. I could pop up a dialog asking for a removal summary upon deletion, though. With a switch such that users could bypass this dialog (resulting in the current behavior) by setting a variable in their monobook.js (or other skin-specific user-JS file). Is that what you had in mind? Lupo 06:24, 19 August 2009 (UTC)
Found it can be done already, by editing the note in the regular page edit, e.g. here or here - MPF (talk) 12:50, 21 August 2009 (UTC)

Small notes

Like User:MPF above, I have noticed some people creating very small note rectangles. Please help me to find out whether these were created that small intentionally or not. If so, it's OK and there's nothing we have to do, but if these people actually wanted to create larger rectangles, then we do have to do something. (For instance, if they clicked (mouse-down and release instead of mouse-down, drag, release), they might get such small rectangles.)

Please ask the people who create such small rectangles about it.

If it turns out that these were created unintentionally, there are several things that could be tried in the script:

  1. Simply making sure upon display of a note that the displayed rectangle has a certain minimum size, regardless of the note's "real" size. (Something like 6×6 pixels seems fine, the rectangle would be centered over the center of the "real" rectangle.) This could be combined with (2) or (4) below.
  2. Asking the user (through a pop-up alert) at creation time if s/he really wanted to create such a small rectangle if the rectangle size is below some minimum (for instance, if the script detects that the rectangle would be smaller than 6 pixels on a 640px thumbnail).
  3. Simply ignoring such small rectangles on creation: don't open the editor, remove the rectangle, and leave the drawing mode.
  4. Make the script ignore the mouse-button-up event if the rectangle size is small and the event occurred within a very small time since the mouse-button-down event. The script would remain in rectangle drawing mode until the next mouse-button-up event within the image.

Which of these might be best? Or do you have some even better suggestion how we could try to avoid unintentional creation of very small rectangles? Lupo 06:21, 19 August 2009 (UTC)

BTW, there is a tag for such small notes being added: small image notes. Lupo 07:02, 19 August 2009 (UTC)
I would suggest #1 and #4. --Jarekt (talk) 19:05, 19 August 2009 (UTC)
I've done #1. With #4 I'd like to wait until I know whether these were created intentionally or by mistake. Lupo 21:59, 20 August 2009 (UTC)

Feature request: non-rectangular regions

Now that software is released I would like to add an item to the To Do list: support for non-rectangular regions. I was thinking about something like in wikimapia, where you click at multiple locations which are connected by straight lines until you click in the neighborhood of the starting location, which is recognized as loop closing. There are multiple cases where I was not able to draw a meaningful box using a rectangle, for example: leftmost climb in File:Joshua Tree National Park - Intersection Rock.JPG or streets in File:A. Nevsky Cathedral in Warsaw (Aerial).jpg. I believe the point was mentioned before, and user:Lupo reply was that it might be a significant effort, but I would still like to keep it on long-term To Do list. --Jarekt (talk) 19:02, 19 August 2009 (UTC)

It's hard. I would first have to do some research if it is at all possible to draw arbitrary shapes in JavaScript. Off-hand, I don't think there's a way (except the HTML5 <canvas> element, but that's not available on many older browsers. And the WikiMedia projects don't serve HTML5 yet (though there are efforts to get there); for now, it's still XHTML 1.0 transitional.) The next problem is what to do with that region afterwards. You need some HTML element to which to attach event handlers that pop up and hide the note text when the mouse enters or leaves the element's region. HTML elements are all rectangular: the layout is based on a box model. Events fire based on that rectangular box, not on the arbitrary shape it might contain. So you'd need to roll your own event handling, tracking the mouse (doable) and checking yourself whether the mouse entered or left such an arbitrary region (a little harder) and then fire your own events (doable, but requires some effort). So, unless pages are served in HTML5 and we have a reasonable fallback for browsers not supporting it, I don't see how it could be done.
Apart from these technical issues, it'd also require rethinking part of the user interface: how to choose which shape to draw.
We may keep it on some really long term wish list, but a to-do list should, IMO, contain items that one can expect to be resolved in the near to medium-term future (a few months at most). Lupo 20:23, 19 August 2009 (UTC)
Than lets keep it in mind, maybe with the better software in the future (HTML5). I noticed this kind of capabilities within Wikimapia and assumed (probably incorrectly) that we could have similar capabilities. See for example http://wikimapia.org/wiki/Adding_place#Polygons. I was also imagining that a code for that could be found instead of written from scratch. --Jarekt (talk) 02:52, 20 August 2009 (UTC)
Well, look at the page source of Wikimapia. Frankly said, I don't know what they're serving. Seems to be SVG with HTML, and based on the Google libraries. I don't think we can do that here reasonably, but maybe some developer might have an idea. Lupo 20:45, 20 August 2009 (UTC)
Why not use HTML imagemaps for this? 85.218.34.154 08:48, 26 October 2009 (UTC)

Text should not appear over boxes

Annotations should not cover up the part of the image they are describing. Compare: flickr commons Doodle77 (talk) 05:07, 19 August 2009 (UTC)

I could make the texts appear relative to their box instead of relative to the mouse pointer easily enough, but that would mean that for large boxes, they'd appear far away from the mouse pointer. And the mouse pointer is where the user's attention is focused. I'd like to have more input on that one. What do others think? (Note that the note covering its rectangle can be avoided easily enough by the user by just moving the mouse and leaving and re-entering the rectangle at the bottom border of the rectangle.) Lupo 06:10, 19 August 2009 (UTC)
I agree this could be improved. What usually happens to me (at least when I'm moving my mouse slowly) is that the annotation covers up the box, and my pointer covers up part of the annotation. This can be annoying, especially when the box is small and ends up completely covered by the text. On this image, even approaching the box from below doesn't prevent it from being completely covered. Always displaying the annotation below the box seems acceptable: when something new appears on the image, it attracts the attention of the user. But I don't think this will solve all issues. Currently, annotations are displayed such that the cursor is inside the annotation, close to the top left corner. Maybe you could display it with the cursor just outside of the annotation, very close to the top left corner? What might be even better would be to have the cursor close the bottom right corner if you enter the box from the left or above, and close to the top left corner if you enter the box from the right or below. Pruneautalk 14:30, 21 August 2009 (UTC)
It happens to me also, no matter how carefully I approach the box, the text will cover it up: see here. Not a big issue, but indeed it would be great to have the text displayed at more distance. - Keta (talk) 18:04, 21 August 2009 (UTC)
Please take note that our notes are different from Flickr's. Flickr notes can, AFAIK, contain only simple text, but not links or other clickable elements. Our notes may contain anything, in particular links that can be clicked. Now consider:
  • The current implementation shows a note when the mouse enters the note's rectangle, and hides the note again when the mouse isn't inside the rectangle or inside the note anymore. If there was a gap between the rectangle and the note, the mouse could never get into the note to click a link there: as soon as the mouse cursor left the rectangle, the note would disappear. Therefore, our notes must overlap their rectangles.
  • I could change the implementation to display the note at a fixed offset from the rectangle instead of relative to the mouse position, and not hide the note when the mouse leaves the rectangle. Notes would get an extra close button. Notes would disappear when closed explicitly, or when another note popped up. (You do need this, otherwise moving the mouse across an image with several rectangles would popup all the notes, and you'd have to close them all manually. You really, really don't want that.) However, that still doesn't resolve the gap problem. If the gap betwen the rectangle and the note actually belonged to another note's rectangle, that other note would pop up as soon as the mouse left the current note's rectangle. The current note would still disappear and be replaced by the newly entered rectangle's note. Therefore, notes still would need to overlap their rectangles.
For small notes, the difference between the current implementation and one which displayed the note relative to the rectangle (but still overlapping the rectangle a bit) is minuscule. I don't think it's worth any code change. As a work-around, I'd suggest making the box here a bit larger. Lupo 12:08, 23 August 2009 (UTC)
I've made it a bit larger (250 × 120 px) - MPF (talk) 22:21, 23 August 2009 (UTC)

Feature request: display crops of note areas

This is probably obvious, but it would be cool if automatically cropped images could be displayed by invoking the ID of a note as a parameter in the image syntax.--ragesoss (talk) 23:12, 19 August 2009 (UTC)

It would be interesting to have a list of notes for a panorama with a crop of the corresponding section. Clicking on an item in the list would highlight/move to the corresponding part of the image/panorama. -- User:Docu at 01:44, 22 August 2009 (UTC)

Colour options

How difficult would it be to add an option to change the rectangle colour? I noticed someone added very useful notes to File:Prequile lyon 1863.jpg, but the yellow of both image and rectangles makes it very difficult to find them. More options - red, blue, green, purple, etc. - would be great; or perhaps even the option to use html colour codes? Cheers, and thanks for the great new gadget! -- Editor at Large • talk 02:31, 22 August 2009 (UTC)

That would be possible, but a user interface for setting that isn't exactly straight-forward. I would suggest a low-key approach: A new template "ImageNoteColors" with three parameters (normal, highlight, newnote) which might be any HTML color specification ("red", "blue", "#FFFFFF", etc). To define the colors of the rectangles, you'd just place that template onto the page (by editing the page normally). The script could check for that template's presence and use the specified colors. Note that such a feature would be open to abuse, like deliberately setting the colors to identical values, or to colors that are hard to see. (The script would check at least that the newnote color for drawing the rectangle was not the same as the "normal" color, and use a built-in default color different from the normal color otherwise.) If something like that were implemented, I'd also add a switch to the script to tell it whether to honor such user-defined colors (the switch could be activated by defining a variable in one's monobook.js, or by appending a parameter "imagenotedefaultcolors" to the url of the page). Would something like that be acceptable? Lupo 08:28, 22 August 2009 (UTC)
That sounds good to me! There probably will be some vandalism and some people adding notes just to play with colours and whatnot, but that's to be expected. There's less note vandalism than I thought there would be, so hopefully "colour vandalism" won't be too rampant either. Cheers, -- Editor at Large • talk 21:44, 24 August 2009 (UTC)
Well, the idea was to have regard only the first such template on a page. At least all the notes on an image would have the same colors. Lupo 22:03, 24 August 2009 (UTC)
Since the subject has been brought up, let's have rectangle colours as requested, not 'colors' ;-) MPF (talk) 22:02, 25 August 2009 (UTC)

Where is the data stored?

Where annotation data for each image stored? If someone deletes a note I added, is there a history where I can see the pre-deletion note?--ragesoss (talk) 21:30, 24 August 2009 (UTC)

Notes are stored on the file description pages. Any edits made through the ImageAnnotator interface result in normal edits to the file description page. They can be reverted or undone like any other edit.
If you're asking whether you could run ImageAnnotator on an old version of the page: no, not yet. Maybe in version 2, but I'm not promising anything. Lupo 22:06, 24 August 2009 (UTC)
Need to figure out how to disallow IPs from removing notes. I'm guessing it's not possible since it's just a simple click of the edit tab to remove it. - ALLST✰R▼echo wuz here 06:06, 25 August 2009 (UTC)
You want to forbid IPs to undo other IPs' test edits ([3], [4], [5]) or their own tests ([6], [7], [8])? Doesn't sound like a good idea to me. Besides, as you pointed out, it could also be done by editing the page directly. Lupo 06:58, 25 August 2009 (UTC)
Thanks. I feel silly; I assumed that's how it worked at first, and then I got sidetracked and confused myself and forgot to actually look at the markup.--ragesoss (talk) 16:58, 25 August 2009 (UTC)

Protected pages

I tried to add a note to File:79 - Québec - Juin 2009.jpg (tomorrows FP), but couldn't save it (it's protected). The error message displayed is "Exception Error: Server reply does not contain mandatory form. Could not save your note (edit conflict or other problem)." Possibly it could be more explicit. -- User:Docu at 01:41, 22 August 2009 (UTC)

Hmmm. Interesting that you got the edit links at all—you shouldn't even get them on pages that you cannot edit. Looks like you've found a bug. I'll investigate... Lupo 08:17, 22 August 2009 (UTC)
Ok, not a bug. The file is cascade-protected, and such pages have no indication anywhere that they are currently protected, you only notice it when you click the "edit" link. I'll see if I can get that info from the server (and suppress the edit part of the user interface then), and I'll update the error message for such cases. Lupo 08:49, 22 August 2009 (UTC)
Thanks for looking into this. If it's just for cascade-protected pages, it might not matter that much. --User:Docu 23:32, 23 August 2009 (UTC)
If you can get that information from the server, hopefully they can add the function to the {{PROTECTIONLEVEL:}} magic word too. It would be really useful. Rocket000 (talk) 18:41, 27 August 2009 (UTC)
It is available through the API and already fixed in version 2. Lupo 20:27, 28 August 2009 (UTC)

Feature request: translatable summary

The tool ha been enabled on hu.wikipedia (though only in the File namespace - is there any point in loading it in other namespaces? with five or six JS files, it is quite costly), but the only way I found to get Hungarian edit summaries was changing the code. It would be nice to have a more maintainable solution. --Tgr (talk) 12:33, 28 August 2009 (UTC)

I can also make the summary a configurable message. Something for version 2.
As it being costly: since JavaScripts are cached on the client, it isn't that costly at all. Were the instructions on the help page correct? BTW, you'll be in for some more work when version 2 is released.
Yes, it may make sense running it in other namespaces, too. See Help:Gadget-ImageAnnotator#Local annotations why. And with version 2, which can display notes on images directly in articles, it makes even more sense to run it other namespaces, too. Lupo 14:13, 28 August 2009 (UTC)

My theory is that Wikipedia visitor distribution has a long-tail effect: most visitors only come a few times a month and only stay for a few clicks (Commons probably has a different usage pattern). So the scripts would have to be loaded for a significant fraction of the page views. Article-specific annotations probably don't justify that. (Then again, it shouldn't be too hard to load them only if there are annotations on the page... anyway, I'll wait and see if people even use the thing. :-) Showing the annotations from the description page in some sort of pop-up lightbox in the articles would be very cool though.) --Tgr (talk) 18:31, 28 August 2009 (UTC)

The instructions worked fine, though I didn't follow step 4 (I wanted it to load only when necessary). --Tgr (talk) 19:15, 28 August 2009 (UTC)

A related question: can I put descriptions (between noinclude tags) into the two templates whose Commons versions don't have them? --Tgr (talk) 19:20, 28 August 2009 (UTC)
Which two templates? Lupo 20:26, 28 August 2009 (UTC)
Template:ImageNote and Template:ImageNoteEnd. Nevermind though, it was a stupid question; it is quite obvious that it can be done. --Tgr (talk) 21:12, 28 August 2009 (UTC)

Suggestion: new namespace for annotations

Apologies if this is suggested the nth time :-) Why not transclude the annotations from a separate namespace? That is, set an Annotation namespace, and put {{Annotation:X}} File:X. (Or preferably a template that does that and says there are annotations. Or maybe even a MediaWiki message could be used to that on #ifexist.) A few advantages:

  • much easier for the script (and possible other interfaces like bots) to fetch/parse the annotations
  • easier to police (a simple namespace filtering could replace the AbuseFilter request a few sections above), create stats, etc.
  • notes wouldn't clutter up file description sources
  • could use the template internalization mechanism to have multilanguage annotations (admittedly a horribly ugly way to do that, but still better than loading every annotation in every language for every reader)
  • loading annotations through the API (when the reader is not looking at the description page directly) would not require loading all the cruft on the description page, and would be easy to internationalize
  • changing the annotations would not require changing the description page -- probably helps license patrollers to keep their sanity (if FlaggedRevs is enabled for file description pages in the future, which seems like a logical step for Commons, it would help even more)
  • could edit annotations of protected images

Possible disadvantages:

  • image renaming, if ever enabled, would cause complications
  • people watching the page would not see changes in annotations -- not sure whether this is actually good or bad
  • MediaWiki does not support multiple template namespaces, notes would be cached and change slowly (probably easy to fix on the software level)

What do you think? --Tgr (talk) 19:07, 28 August 2009 (UTC)

No, very bad idea. It actually makes it very hard for the script to detect edit conflicts. Please read Help:Gadget-ImageAnnotator#Frequently asked questions, #1. Lupo 20:25, 28 August 2009 (UTC)

Um, are you not using the edit API? Detecting edit conflicts should be trivial that way, you just get an error message if it happens. --Tgr (talk) 21:09, 28 August 2009 (UTC)

I doesn't matter. (Incidentally, no, I'm not using the edit API. No need to have the write API switched on.) The script would need to detect edit conflicts between new image uploads and edits to that separate notes page, i.e., conflicts between two different pages. Detecting edit conflicts on one page is easy, but inconsistencies between several pages can quickly become a nightmare. And the script would need to query the notes page separately, which increases startup time as it requires yet another request. Presumably you'd also want a separate notes page to have the same protection setting as the image page, so you'd get even more coordination headaches. It's not a good idea to split things that belong together over several objects that can be independently manipulated. It's just asking for trouble. Lupo 22:39, 28 August 2009 (UTC)
Oh, and deletions and manual "renamings" of images would also need to account for there possibly being separate notes pages. Lupo 22:43, 28 August 2009 (UTC)

Special:AbuseFilter/47

Would someone reactivate the log? The log seems readable to me. -- User:Docu at 15:49, 26 August 2009 (UTC)

I don't think that's a good idea. For example, look at your abuselog entries. All, or probably most of them are more than acceptable contributions. This also applies to several other users as well. The abuse filter is to log or fight possible vandalism, not to log the usage of a tool. I can understand your desire to log it, but the abuselog isn't the right way, as this is for vandalism issues. For example, we also don't log the usage of HotCat (except on template pages, which has its reasons). --The Evil IP address (talk) 18:46, 26 August 2009 (UTC)
Readable, yes. Useful, no. This filter completely floods the abuse log with perfectly good edits and there's no current way to filter these out. There's also no way to have it tag only and not log. Testing filters against recent edits already isn't easy to do since the testing tool only does 100 edits at once. For the most part, testing filters to make sure they're working right depends on reviewing this log. Many of our real abuse filters are not currently doing anything or very little because we are still developing/refining them and cutting out the false positives. Maybe expanding MediaWiki:Gadget-rightsfilter.js to work on RC and the abuse log would be a solution? Rocket000 (talk) 18:55, 26 August 2009 (UTC)
BTW, there's two other filters that log ImageAnnotator edits selectively: 48 and 49. Rocket000 (talk) 18:59, 26 August 2009 (UTC)
(editconflict) One shouldn't see log entries as "abuses". It's just a filter system to make it more easier to read Special:RecentChanges. By removing the filter, we make this more difficult to read. It's a bit odd that The Evil IP address would remove this filter without prior discussion. We added it after it was discussed it on VP. Please reactivate it. -- User:Docu at 19:01, 26 August 2009 (UTC)
Well, it is called Special:AbuseLog for a reason. You're only looking at one part of Commons (the part you're interested in). I would like to tag certain things too that I'm interested in tracking, but the abuse filter isn't suited for that purpose (but something like the javascript filter gadget is). It makes the log practically useless. It's like a unflagged bot destroying the recent changes. In this case, it's not the RC watchers that are affected, it's the people that help maintain the abuse filters (which includes Evil IP) that are the ones that see the problem since they have to deal with it. Rocket000 (talk) 03:33, 27 August 2009 (UTC)
Exactly. Furthermore, I've talked to Ilmari Karonen, if he knows a better solution of the problem, but who said that the filter should be disabled if it's flooding the abuse log. --The Evil IP address (talk) 05:41, 27 August 2009 (UTC)
The obvious fix is to submit a bug report on that extension. It should allow two things:
  1. Specify filters that don't log the edit in the abuse log.
  2. Filtering of the abuse log. Two operations are needed: exclude certain tags, show only certain tags. Would need some interface similar to the search (which namespaces to search), and a preference page for defining a per-user default setting.
Seems to me with that, this filter #47 could be enabled, and people not interested in it could just set their AbuseLog prefs to exclude it from the list. BTW, how does tagging work? Can an edit be matched (and tagged) by multiple filters? If not, that'd be yet another feature we'd need. Lupo 05:49, 27 August 2009 (UTC)
The AbuseLog extension is far from perfect. I really don't know how filters interact with each other, but there is some kind of order they must run in. If an edit triggers more than one filter, a log entry is created for each (so hypothetically a single edit can fill up a whole page of the log, but that would take some seriously bad filter writing and planning), yet it seems only one filter's set of actions (tag, warn, disallow, deautoconfirm, etc.) is preformed. There is no obvious way to predict which filter will take precedence (see one issue I ran into). Rocket000 (talk) 18:30, 27 August 2009 (UTC)
To select several log entries at once, couldn't we add additional ones to some of the entries. The tag could be really short, e.g. "G1" (group one) etc.? This way we could write one for unproductive renames of high use templates and one could look at these without having to check image annotations ("G2"). If someone would like to look at categories, the various filters could be in "G3". All smears would be in "G4" and so on. To select annotation by new users only, one would use "image notes by new users" instead of "G2". If you add me to the user group, I could set it up. -- User:Docu at 11:15, 28 August 2009 (UTC)
I'm not sure what you mean, but it doesn't sound like anything that's technically possible on our side. It would be something the extension devs would have to implement. You can select multiple tags to filter the RC with (put a comma between them), but that's not the issue. When we watch the abuse log, we can't select filters (and thus tags) to filter out of the abuse log. Normally, you don't need to because you either want to see all edits or only those for one filter. The abuse log is to help us make sure all the filters are working properly (especially right now while we're still trying to get the basics in place). This is probably why there's no log filter already built-in. I mean they did call it AbuseFilter and probably never considered that anyone would ever want to (or have to) filter non-abuse from the log. BTW, I am not strongly opposed to re-enabling this but for the long term this is just not workable solution with the current software. Rocket000 (talk) 04:53, 29 August 2009 (UTC)
Oh, and there's currently no separate usergroup here for the abusefilter-modify right that I could even add you to. Admins have it but can't assign it. Rocket000 (talk) 05:04, 29 August 2009 (UTC)
Looks like the user groups are different from en.wp. Over there, there is a user group just for filters.
Back to the initial issue: It seems possible to assign several tags by the same filter. One could include a tag that groups several filters (e.g. "G1"). To avoid some entries, one could check the log for a group tag. I didn't know about the comma thing, but in this case, I don't see why Evil IP wouldn't just list the ones he would want to see. (Once his done with renaming templates, I mean). -- User:Docu at 12:57, 29 August 2009 (UTC)
Hm, if you are specifically concerned with the Special:AbuseLog screen, it is a bit harder. In firefox one could just highlight all entries of one filter and check the other ones. The suggested approach works mainly with the Special:RecentChanges screen. In the meantime, one would have to check Special:RecentChangesLinked/Category:Images_with_annotations. This doesn't work for removals though. -- User:Docu at 13:13, 29 August 2009 (UTC)
Yes, the RC log isn't the problem. It's the abuse log. I think I get what you're saying: Create new filters that combine multiple filters so that if an edit triggers that specific combination, it is tagged with a tag that's a combination of the respective filters, right? That won't work either because you have the same problem. There's no way to make that tag be the one applied. It's still going trip the individual filters as well.
When you mention highlighting in the browser, I remembered that tags can actually be styled (with CSS). I totally forgot about that, even though I recently changed them to all use small text. Making them different colors would help a little. Rocket000 (talk) 01:42, 30 August 2009 (UTC)
From logs at smaller wikis, one might think that everybody could monitor each entry in the log, but at least at the larger wikis, it seems obvious that one can look at the one or the other tag only. To select several of the other filters, one could add one or several additional tags to these. BTW I asked to update the description of the logs at MediaWiki talk:Abusefilter-log-linkoncontribs -- User:Docu at 10:37, 27 August 2009 (UTC)

Note removals

It happens once in a while, that people remove notes (it's even easier than undoing edits). From the edit itself, there is no way to know if they are removing a note they think is erroneous. To address this, the tool should probably prompt users to enter an explanation. If one removes things, it's fairly standard to provide a reason in the edit summary. -- User:Docu at 13:18, 29 August 2009 (UTC)

Was on the to-do list, and is done now in version 2. Lupo 14:06, 29 August 2009 (UTC)
That was quick. Thanks! -- User:Docu at 22:06, 29 August 2009 (UTC)
Well, version 2 not rolled out yet. It's planned for the second half of October. Lupo 23:21, 29 August 2009 (UTC)

File:Wojciech Kilar 2.jpg

For some reason User:Mdale was able to edit the page. -- User:Docu at 16:39, 28 August 2009 (UTC)

meta:User:Mdale probably explains it. I haven't figured out the user group he is in. -- User:Docu at 16:42, 28 August 2009 (UTC)
Michael Dale is a developer, responsible for the new upload stuff (not yet deployed here). I'd guess as a core dev he has write access anywhere. But it is weird, the other devs (Brion, Tim Starling, ...) are stewards. Lupo 20:22, 28 August 2009 (UTC)
He has the staff right (Special:GlobalUsers/Staff). It's not listed in Special:ListGroupRights but here's the edit history of the usergroup. Rocket000 (talk) 06:13, 29 August 2009 (UTC)
Apologies for the test annotation on that image (was demoed at wikimania and forgot to revert) Mdale (talk) 20:00, 30 August 2009 (UTC)

MediaWiki feature which could be used

I saw in earlier versions of this template used {{urlencode:}}. In template w:User:Dispenser/Checklinks/config I used {{#tag:nowiki|text to be escaped}} to encode text to be quoted. Unfortunately, this does not work with comments <!-- -->. Dispenser (talk) 07:44, 1 September 2009 (UTC)

That was a very early version. (And it didn't use {{urlencode:}}, that doesn't work properly with arbitrary wikitext (e.g., containing <nowiki> or <gallery> or other tags). Instead it urlencoded the wikitext in the script.) The deployed version of ImageAnnotator works without any such hacks. Lupo 07:51, 1 September 2009 (UTC)

Position of the ImageNote on the edit page

Can it be changed so that the ImageNote goes above the Categories, not below them? And preferably also with a line space above and below the ImageNote so everything is more clearly visible? e.g. as here - Thanks! MPF (talk) 22:41, 25 August 2009 (UTC)

And what if the only categories in the page are above the "== License ==" header? Lupo 06:25, 26 August 2009 (UTC)
They ought to be moved below! Not sure whether that would be feasible with the note-adding software, though. - MPF (talk) 10:33, 26 August 2009 (UTC)
No, unfortunately, that's not possible in general because it would need a full-blown wikitext parser. Lupo 10:53, 26 August 2009 (UTC)
Would it be possible to insert a blank line before the ImageNote block? That would it make easier to quickly see where categories (or licenses) end and where the ImageNote starts. --Matt314 (talk) 19:26, 1 September 2009 (UTC)
Couldn't you add the notes below the last line not starting with [[Category:? Then they'd be in the right position on all pages, and you wouldn't need to parse the rest of the wikitext. I also support the addition of blank lines. Pruneautalk 20:41, 1 September 2009 (UTC)
That would still append at the end of the page if the categories were above the "== Licensing==" header. And on other Wikis, where people might use localized namespace names or namespace aliases instead of "Category", the script would need to get a list of localized namespace names from the API to be able to also handle [[分类: and [[分類: (example from zh-WP) or [[Kategorie: (from de-WP). It's a lot of complexity for very little benefit. The currently active version appends new notes at the end or inserts them just after the last already existing note. That is, once notes have been moved to correct place, new notes will be added in the correct place. But automatically figuring out that correct place for the first note is not easy...
As to adding empty lines around the note block: inserting them is easy, but it will complicate note removal a bit because you'd also want these empty lines to be removed when the last note is removed from a page. Lupo 15:14, 2 September 2009 (UTC)
One could suggest to add a new function to Mediawiki. It would re-format wikitext upon page save (automatically or as an option). It would, e.g. place all categories at the end of a page (or before iws). This might be useful for other wikis too. -- User:Docu at 19:16, 6 September 2009 (UTC)

Long load time for Firefox 3.5.2

The notes take a very long time loading for this version of Firefox. You could check http://commons.wikimedia.org/wiki/File:Quartz,_Tibet.jpg --Diaa abdelmoneim (talk) 17:30, 30 August 2009 (UTC)

That file doesn't have and never had any notes?! Anyway, Firefox 3.5.2. is buggy. Just google for "firefox", "3.5.2", "cpu usage". Firefox 3.0.x doesn't have such problems. But I'll check whether there is something specific in ImageAnnotator that might trigger that FF 3.5.2 bug. Lupo 19:14, 30 August 2009 (UTC)
I mean it keeps loading for a long time (about 30 secs) after the image has loaded, before the add note button shows up.--Diaa abdelmoneim (talk) 23:21, 30 August 2009 (UTC)
Cannot confirm. Loads fine (and quickly) for me in FF 3.5.2. Lupo 06:45, 31 August 2009 (UTC)
I am experiencing the same problem with FF 3.5.2 but mostly with SVG images. In some cased the loading takes 10-15 minutes, but my theory is that it is not annotators fault but a problem with some other stuff that loads prior to the annotator. I occasionally have the same issues with icons above and below edit window in regular edit mode. --Jarekt (talk) 17:58, 7 September 2009 (UTC)

Usability Question

I've been adding notes and came across File:Wounded Knee aftermath3.jpg which needed such notes to define the dead bodies. Is there a better way to define the bodies?--Diaa abdelmoneim (talk) 08:27, 8 September 2009 (UTC)


Background around included images in read-only (at Wikipedia)

If viewed in viewed in the read-only version, the images included in annotations are displayed differently from the edit mode version.

Compare, e.g. File:Le_Grand_Palais_depuis_le_pont_Alexandre_III_à_Paris.jpg with the version at one of the wikipedias that already have it installed. There the background does not extend around the image. It doesn't seem to happen if thumbnailing isn't used (sample: File:Spelterini Blüemlisalp.jpg)

It's just a matter of personal preference, but I prefer the version with the background around text and image. -- User:Docu at 04:04, 16 September 2009 (UTC)

Thumbnailing uses a floated div to display the images, and such a floated div may extend beyond the borders of the containing structure (the popup). As a temporary fix, I've added a {{-}} in that note. I'll make sure that in version 2, this will be added automatically. Lupo 06:54, 16 September 2009 (UTC)
✓ Done in version 2, currently scheduled for deployment on October 17, 2009. Lupo 07:47, 16 September 2009 (UTC)
Thanks! -- User:Docu at 05:00, 2009 September 18

Exception Error

Exception Error: Version inconsistency after saving. Please reload the page. Could not save your note (edit conflict or other problem). Please copy the text in the edit box below and insert it manually by editing this page. Text of the note (may include Wiki markup) 

{{ImageNote|id=2|x=55|y=443|w=68|h=59|dimx=1239|dimy=936|style=2}}
{{en|1=heavy chain freely rotating<br />with ADP occupying the ATP binding site}}
{{ImageNoteEnd|id=2}}

(I put the pre tags around the edit box contents above.

The ImageAnnotator tool is reporting this error for each note I add to File:Motility of kinesin en.png and yet the saved version has the correct revision. It is as if the tool is reporting an edit conflict with myself, or as if it is trying to add the note a second time.

This problem does not stop me adding notes, so it is not that important, but I bring it up in case others are seeing the same thing. -84user (talk)

This is caused by the recent server-side changes. I'll fix it right away. Lupo 13:25, 17 September 2009 (UTC)
✓ Done. Please reload your browser's cache. Lupo 13:39, 17 September 2009 (UTC)

Fix confirmed. Wow, you are quick. It now works with no error. Thanks. -84user (talk) 14:36, 17 September 2009 (UTC)

Maintainer temporarily off-line

I'll be away until mid-October. If any urgent technical problems with ImageAnnotator come up, please ask some other JavaScript-savvy admin for help. User:Ilmari Karonen and User:Dschwen are two who might be able to help. Lupo 14:08, 18 September 2009 (UTC)

Default box size

I was in the process of annotating File:First_Female_Astronaut_Candidates_-_GPN-2002-000214.jpg and instead of clicking and dragging I just clicked and a default box was created. I was wondering if this default box could be made larger about maybe 50px so that their faces would fit in without the need to drag. Most users that come to annotate don't know that they can drag to edit the box's size so they just click and small boxes are created. Can't the default box be a bit larger to encompass more objects?--Diaa abdelmoneim (talk) 00:13, 30 September 2009 (UTC)

I think it's not a default size you are currently getting, but the minimum size. -- User:Docu at 10:38, 1 October 2009 (UTC)


Feature request: zoom on highlighted area

For cross-referencing: there is an interesting feature suggestion included in this comment. -- User:Docu at 10:38, 1 October 2009 (UTC)

Version 2 activated

I have, after extensive tests, activated version 2 of the ImageAnnotator.

Changes:

  1. Somewhat faster display: UI is gotten in parallel, and is cached (4 hours).
  2. Sluggish display of notes on IE is fixed.
  3. Minor bug fixes in support libraries.
  4. Minor bug fix for cascade-protected pages, which were not detected in version 1.
  5. Some internal code cleanup.

New features:

  1. Is enabled on old page versions (but not on diff pages).
  2. Prompts for a removal reason when an existing note is removed.
  3. Colors used for the note rectangles can be defined on a per-image basis. See {{ImageNoteColors}}.
  4. Edit summaries are configurable, too.
  5. Display notes on thumbnails and other images, for instance in article pages. With configurable support to display only an indication icon on such inline images instead of the notes themselves. Global site-wide config can determine where to display (or not) notes. Users can additionally switch off note display selectively for thumbnails or other images on a per-namespace basis, or can tell the script to only display an indication icon.
  6. Support for global default configuration (in which namespaces to activate, for which users).
  7. Support for defining note display on images used in articles on a per-image and additionally a per-article basis.
  8. Support user-defined switching off of note display on thumbs and other images based on namespace.

Help:Gadget-ImageAnnotator has been updated to also document the new features.

If despite my tests something goes wrong somewhere, please notify me here or on my talk page.

(Note: to get version 2 running on your browser, you need to refresh your browser's cache. Otherwise, your browser will get the new version on its own sometime within the next 30 days.)

I hope all goes well... Lupo 11:56, 28 October 2009 (UTC)

Error on OGV files

I'm getting an error on a video page File:Denton,_Texas_sightseeing.ogv. It might be a cache issue. It occurs under FX 3.5 but not Chrome or IE.
TypeError: img is null
http://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-ImageAnnotator.js&action=raw&ctype=text/javascript (1611)
mahanga (talk) 16:32, 28 October 2009 (UTC)
Thanks for pointing this out. ✓ Done It's fixed now. (ImageAnnotator should let you add notes only on jpg, jpeg, png, gif, and svg files.) The exception does not occur anymore. Remember to reload your browser's cache to get the correction. Lupo 21:44, 28 October 2009 (UTC)

Strange behaviour with images that are elsewhere

Some days ago I used ImageAnnotator version 1 in a delete request (see here) to show a specific point, but now it apparently doesn't work anymore (unless the Commons: namespace is switched off by default). OTOH, it currently works fine in my sandbox User:Ianezz/Sandbox. -- IANEZZ  (talk) 15:53, 29 October 2009 (UTC)

I know, I've seen that, too. The problem is caused by the "center" in the image link. ✓ Done That's fixed now, though the text and the "Add a note" button are not nicely centered below the image. Just refresh your browser's cache, then it should work again also on that DR. Lupo 16:48, 29 October 2009 (UTC)
Works fine now. Thanks. -- IANEZZ  (talk) 17:15, 29 October 2009 (UTC)

IE8 blocks

Two people using IE8 have reported that IE8 gets very sluggish in some cases. I'm still investigating this. It's evidently some crazy event handling problem that I cannot track down in a snap; this needs more time. I have therefore reverted back to version 1. I first need to solve this IE8 problem, and I don't know how much time I'll need to do so. Lupo 09:03, 30 October 2009 (UTC)

And scratch that. The problem has been found, a work-around has been found, and I have confirmed that it works. So we're still (or again, after an 11-minute interruption) running version 2.
A big hearty thanks to User:Fran Rogers, who had tracked down the bug and found a fix. Awesome! (I know how difficult it can be to find one's way in code one hasn't written oneself!) Lupo 09:34, 30 October 2009 (UTC)

Disabel this gadget for non-loged in users

I stumble upon these annotations from time to time. I have not seen a single one that was useful. I think a lot of non-logged in users don't even want to vandalize they just click on it accidentally and then don't really know how to exit without saving. I would strongly suggest to disable this for non-logged in users or at least make it a tab so people don't accidentally click on it. --Cwbm (commons) (talk) 19:32, 2 November 2009 (UTC)

You might like to look at images in Category:Images with annotations for images with useful annotations. I would guess about 80% of images there have annotations meeting com:ann guidelines. Most of the useless annotations I have seen came from new logged contributors to Commons who upload new images and add information related to the whole image using annotations. --Jarekt (talk) 21:16, 2 November 2009 (UTC)
Because the images with useless annoatations are kept in Category:Images with useless annotations. --Cwbm (commons) (talk) 05:51, 3 November 2009 (UTC)
Just have a look at recent notes by not-logged-in users. A few of them are informative, but it seems to me that the most part is garbage. I too proposed in the past to restrict adding/modifying notes through the gadget (i.e. the "easy" way) to logged in users. Perhaps we should wait a bit more, do some math on the logs (i.e. over a couple of months) to compute the sound/noise ratio, and then take a decision. -- IANEZZ  (talk) 10:21, 3 November 2009 (UTC)

I am trying to modify the script behind the multi lingual description, but I am encountering a very weird issue correlated with the image annotator. (my version is there: User:Esby/testls2.js)
The images annotations are not 'mld' displayed correctly under some conditions: if the user has not highlighted the note before restricting to a language, the language restriction simply won't work.
This seems linked to the creation of a div structure which appears to be a copy or a clone of the intitial annotation, as the number of div structure in the document increases when you highlight one annotation...
Now my problem is that I have no idea on how to try to fix that... I don't even know if duplicating the div structure is intented here.
Esby (talk) 22:30, 12 February 2010 (UTC)

Please see Help talk:Gadget-ImageAnnotator/Archive01#Suggestions. In addition to the cases mentioned there where the JavaScript-based {{Mld}} wouldn't work right even if that copying of the div was avoided I should add now a third case: it wouldn't work for any note displayed directly on a thumbnail in an article, again because these notes are loaded dynamically and the LangSelect script runs only once when the page is loaded. Lupo 22:56, 13 February 2010 (UTC)
Well technically, on the version I am modifying, it is working, but it needs the user to hover the notes and force selection of the language (by clicking on the button) twice. Basically, could it be possible to preload the cloned div and just display them when hovering ? Another solution would be to have some sort of callback to update the div when they are cloned. The problems for me lies in the fact that the div are created on the fly while hovering them, and that the mld script does not react to the hovering. There might be some viable options but I am not good enough for now to detect those. Esby (talk) 23:35, 13 February 2010 (UTC)
Am I right in my analysis in thinking that first the image annotator is run, then the mld script and later the image annotator will clone the div? In this case, is it possible for the div to be cloned with the same property as their ancestor? (This is the visibiliy property of the div or span of having class='lang-XX' and language 'XX'.) Esby (talk) 00:01, 14 February 2010 (UTC)

Allow saving without summary

Can we not require a summary when removing notes? I find this an inconvenience when reverting vandalism/nonsense (the main reason anyone removes a note). Anyway, summaries should be optional regardless. Rocket000 (talk) 02:39, 28 February 2010 (UTC)

An edit summary for note removals was requested several times in the past (see the archive), which is why I implemented it in version 2. Now, of course that can be made optional, or configurable such that a site-wide configuration setting determines
  • for whom the summary is mandatory,
  • for whom ist is optional, and
  • who may suppress the alert altogether in a user-specific configuration (variable in monobook.js).
The choice would need to be based on wgUserGroups. My suggestion would be (2 & 3) admins & rollbackers, (1) everybody else. Note that notes can also be removed by rollbacking or undoing the respective edits to the page using the normal rollback/undo links in the page history. Lupo 17:17, 28 February 2010 (UTC)
The prompt for a summary is a great thing, I wasn't complaining about that. It's just it should allow nothing to be entered (instead of canceling the action). I would make it optional for everyone and allow admins/rollbackers to suppress it completely with js. We don't make regular edits have mandatory summaries, I don't see why we need it here. Is there a problem with regular editors removing good notes or something? Rocket000 (talk) 18:34, 28 February 2010 (UTC)
Well, maybe the problem has vanished for us since we restricted editing of notes to autoconfirmed users anyway. In general, an implementation would still need to be configurable as outlined above; the rest is then just figuring out what a practical configuration would be.
We could just as well start with a configuration that allowed anyone to suppress the prompt completely, and restrict the configuration if any problems surfaced. (Configuration changes propagate within four hours to anyone; the script explicitly overrides the 30-day caching period impose dby the servers.) Lupo 20:57, 28 February 2010 (UTC)
In general, in a wiki content shouldn't be removed without an explanation. In standard edits this harder to require, but standard edits don't do automatic rollback either.
Thus, the removal without a comment should be limited to Rollbacks/Admins for vandalism. To avoid that this happens by accident, each should enable the config in his preferences or js. This avoids problems that sometimes occur when it seems convenient for some to just use rollback. -- User:Docu at 21:04, 28 February 2010 (UTC)
Yes, summaries are encouraged but they are not policy. We shouldn't use technology to force our POV. If someone really doesn't want to, they shouldn't have to. This is why "remind me to enter a summary" isn't turned on by default. Besides, they can always enter in nonsense. Rocket000 (talk) 23:19, 28 February 2010 (UTC)
I'm not aware that you are authorized to remove content here without an edit summary. Is that so? Wonder why I bother then .. must be a habit from WP. -- User:Docu at 23:23, 28 February 2010 (UTC)
Authorized? You bother because people appreciate it, not because you'll get banned if you don't. Rocket000 (talk) 23:44, 28 February 2010 (UTC)
At least at WP, it gets you blocked in no time. But around here, you get administrators blocking pages because they don't bother discussing .. -- User:Docu at 23:46, 28 February 2010 (UTC)
Really? I didn't know en.wp was like that. Rocket000 (talk) 20:46, 1 March 2010 (UTC)
I'm an en:wp admin, and I didn't know that either. Nyttend (talk) 02:34, 25 July 2010 (UTC)

"Add a note" button missing from File description pages

The "Add a note" button does not seem to appear for me in image File description pages. This is strange, as:

  1. It is possible to view existing annotations on File description pages.
  2. It is possible to edit the File description page, and add Image annotations "manually" using the {ImageNote} and {ImageNoteEnd} templates, after which they can be viewed normally. Based on this, I don't think the problem is a permissions issue.
  3. The "Add a note" button does appear other wiki pages containing images (non-File description pages).

This is true for both Wikimedia Commons wiki, as well as my own personal MediaWiki deployment.

Help:Gadget-ImageAnnotator says:

Normally, the gadget is used on file description pages. On such pages, it is activated automatically.

So it seems like this is a feature that should work. Am I missing something? I'd be happy to provide more information.

Update: After debugging, I can confirm that the above issue is resolved on my local MediaWiki deployments when line 1063 of LAPI.js is changed to the following:

var src = decodeURIComponent(imgs[i].src).replace('%26', '&');
What browser and skin are you using? Does this occur on all file pages, or only on specific ones? And if the latter, on which pages? Lupo 22:18, 30 August 2010 (UTC)

Negative coordinates

I just ran across an image that had coordinates of "|x=-2|y=117". The negative x of course made it not work but there was no indication that anyone even tried to add a note (except for the hidden category, which made me notice this). I'm wondering if there should be something in the script to prevent this (that is, if it still can happen). Maybe we should add a tracking category (or edit filter tag) for invalid parameters via the template? Rocket000 (talk) 22:11, 30 August 2010 (UTC)

The note was added on January 28, 2010, apparently through the script. An early version of the script had a bug that could result in this. As far as I know, it's been fixed long ago. If you find any recent note with a negative number, I'll start digging in the code. Lupo 22:17, 30 August 2010 (UTC)
I did a quick scan on a recent database dump. 78 pages have at least one negative coordinate. I looked at about 20 of them and they were all done before Feburaury 2010 so I don't think it's a problem anymore. Rocket000 (talk) 22:47, 30 August 2010 (UTC)

Text box and editing dialog obscure annotation rectangle

Is there a way to adjust the annotation gadget so that during mouse-over the note does not obscure the rectangle? It often does so for me (Firefox 3.6.9/no other gadgets/Vector skin/English). The text editing dialog obscures the rectangle for me as well (less important, but it would be nice to offset it, too). --Eric my en.wp talk page 14:36, 11 September 2010 (UTC)

No. The note needs to overlap the rectangle somewhat. Our notes are different from e.g. Flickr's. Flickr notes can, AFAIK, contain only simple text, but not links or other clickable elements. Our notes may contain anything, in particular links that can be clicked. The current implementation shows a note when the mouse pointer enters the note's rectangle, and hides the note again when the mouse pointer isn't inside the rectangle or inside the note anymore. If there was a gap between the rectangle and the note, the mouse pointer could never get into the note to click a link there: as soon as the mouse cursor left the rectangle, the note would disappear. Therefore, our notes must overlap their rectangles. Lupo 07:36, 13 September 2010 (UTC)
Ok, thanks for the explanation. I wonder if there's a way to have the note linger briefly and fade out after the cursor leaves the rectangle--just enough time for the cursor to traverse the gap and keep the note active, but not enough to be an annoyance. --Eric my en.wp talk page 13:03, 13 September 2010 (UTC)
And what should happen if you have overlapping or adjacent note rectangles, and the gap belongs to some other note's rectangle? As soon as the mouse moves into the gap, that other note should be displayed... maybe some clever user interface designer could come up with a workable scheme that would allow us to have a gap between the rectangle and its note and that would still feel natural to the user, but I don't see it, and implementing it would be probably quite a lot of work. Lupo 08:56, 14 September 2010 (UTC)
Right, I hadn't thought of other rectangles. I would think one could put buffer zones around the rectangles to avoid those conflicts, but I'm out of my league in that domain. Thanks for the responses. --Eric my en.wp talk page 12:34, 14 September 2010 (UTC)

Image Annotator has been disabled on Commons

The Image Annotator has been disabled on Commons, see Commons:Administrators' noticeboard#Disable Image Annotator for further information. --32X (talk) 11:31, 23 September 2010 (UTC)

Has been re-enabled now per Tim Starling's comment. Lupo 08:02, 28 September 2010 (UTC)

Annotation notes disabled past file reuploading

A added 12 image notes into File:2007-KarlovyVary-053-wide.jpg. However, its uploader uploaded an a bit improved version of this panorama image. All image notes are thereby disabled. Even if I open the old version, those notes aren't displayed. That is a fatal error, that all image notes can be so easily disabled without any warning. --ŠJů (talk) 20:06, 1 December 2010 (UTC)

Hi, I'm the image creator. Sorry about that --I had no idea that such things existed or that I was going to affect them with upload. --Bobak (talk) 20:20, 1 December 2010 (UTC)
Not a "fatal error" at all. The size of the newly uploaded version is different, and thus the old annotations don't make sense anymore. Please read Help:Gadget-ImageAnnotator#Limitations. Lupo 07:54, 2 December 2010 (UTC)
Editing the image size parmeters, the notes appear again. Arno Lagrange ✉ 12:18, 8 December 2010 (UTC)

Add a picture inside the popup

Hello,

Can I put a picture instead of text inside the popup ? I am trying this on this picture (diff) but it seems to be impossible ":" is being added before "File". Teofilo (talk) 13:45, 1 February 2011 (UTC)

IIRC, thumbnails in annotation popups must have a width smaller than 300 pixels. For larger images, it adds that colon, resulting in a link. Hm, maybe I should change that to "<= 300" in MediaWiki:TextCleaner.js. As a work-around, just remove the colon by editing the page directly. Lupo 14:44, 1 February 2011 (UTC)
It won't be necessary. 250px is fine. Teofilo (talk) 00:25, 3 February 2011 (UTC)

MediaWiki 1.17

If you get an error message after adding or deleting a note saying the was a "version inconsistency" or "revision ID not found", please refresh your browser's cache. Lupo 13:16, 16 February 2011 (UTC)

Problem with the categories

Please have a look ath the image in hu:Juan Román Riquelme. It has three categories in annotations that link to Common's categories when looking at the picture in Commons; but when inserted in huwiki, they link to non-existing categories in huwiki, two of which is blue, but they don't work. Bináris (talk) 14:52, 29 May 2011 (UTC)

Apparently it shows the category links as they are on the commons, but the links don't go to the commons. I'm not sure I can do something about this. I'll have to think about it first. Lupo 19:14, 29 May 2011 (UTC)
Prefixing the category by ":en:commons:" works.[9] Alas, simply ":commons:" doesn't work, because "commons" is not an interwiki to the Commons itself here. The only drawback of this hack is that now we don't get a red link for Category:Sebastián Viera... Lupo 19:22, 29 May 2011 (UTC)

Gadget button is not showing on some pages

Although the gadget is OK on most pages (for example File:Middelgrunden wind farm 2009-07-01 edit filtered.jpg) the gadget button ("add a note") is not shown on File:Members of the 6888th Central Postal Directory Battalion take part in a parade ceremony in honor of Joan d'Arc at the marketplace where she was burned at the stake.tif. The "Stockphoto.js" bar is not showing either. See also MediaWiki talk:Stockphoto.js#No buttons on some pages. Teofilo (talk) 21:44, 1 August 2011 (UTC)

It's a TIFF file. For those, the gadget doesn't work. Lupo 20:18, 6 September 2011 (UTC)

Funktion "Notiz hinzufügen" ist weg

Seit heute ist die Funktion "Notiz hinzufügen" verschwunden. Kann mir jemand helfen? --Nikater (talk) 12:36, 7 September 2011 (UTC)

Alles klar. Habe gerade den Fehler behoben, indem ich den Browser-Cache geleert habe. Gruß --Nikater (talk) 12:52, 7 September 2011 (UTC)

Not working

Currently I can't view annotations nor add new ones. What's is happening? --  Docu  at 06:20, 17 September 2011 (UTC)

Don't know. Works for me; see [10]. Try reloading your browser's cache. If it then still doesn't work for you, I'd need to know which browser you're using, which skin, whether there are any error messages in the browser's error console and what they are. Lupo 15:08, 17 September 2011 (UTC)
Thanks for checking. I disabled the "Slideshow" gadget and it works again. I reenabled the "Slideshow" gadget and it still works. Strange. --  Docu  at 21:10, 17 September 2011 (UTC)

bad layout in teamplay with template:extracted from

Annotated images have a bad layout in teamplay with {{Extracted from}}. Example: File:Julius_Schlegel.jpg. Is there a way to disable the looopong note "Diese Datei ist annotiert. Bewege den Mauszeiger über das Bild oben, um die Notizen zu sehen." at small image sizes or in templates? Cheers --Saibo (Δ) 19:58, 30 September 2011 (UTC)

Fixed {{Extracted from}}. See {{NoImageNotes}} and {{ImageNoteControl}} --Jarekt (talk) 20:35, 30 September 2011 (UTC)
Thanks! I Did put it in also here: Image_extracted/row and Image_extracted/single
The bad thing is: images notes are probably not wanted in nearly all templates. Isn't there an easier way than to clutter all templates which embed (variable) images with this kill switch? Cheers --Saibo (Δ) 02:15, 1 October 2011 (UTC)
I do not think there is an easy way to exclude them from all templates. And I agree that there is not many scenarios I can think of when one might want annotations on the images which are part of a template. I think templates that use images smaller than 60x60 are ignored anyway and do not need ImageNoteControl. So it is only an issue with few templates that use larger images. I know that {{Book}}, {{Creator}} and {{Institution}} already block annotations as well. --Jarekt (talk) 03:29, 1 October 2011 (UTC)

Half no more working

Since Mediawiki 1.18, ImageAnnotator works in article page and no more in file pages in eo:WP. Example:

Arno Lagrange ✉ 10:28, 3 October 2011 (UTC)

I'm travelling right now and have only sporadic Internet access. I can deal with this in two to three weeks at the earliest. Lupo 18:57, 7 October 2011 (UTC)
Besides MW 1.18, we also newly have protocol-relative URLs and https support on all WMF wikis. You'll need to install the newest revisions of the various ImageAnnotator scripts at eo-wiki to get it to work again. You'll need to copy the newest revision of
to eo-wiki. Then reload your browser's cache while on a file-page at eo-wiki. After that it should work again. For all users who don't reload their browsers' caches, it'll start working again after at most 30 days. Lupo 09:13, 17 October 2011 (UTC)

Commons:Village_pump#ImageAnnotator

Please see that report on VP. I had this yesterday too. --  Docu  at 04:45, 7 October 2011 (UTC)

This one should be fixed now. reload your browser's cache, and it should work again. Lupo 19:24, 7 October 2011 (UTC)

ImageAnnotator not working

Last few days ImageAnnotator does not seem to work for me. I get "Error: http://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-ImageAnnotator.js&action=raw&ctype=text/javascript at line 1: missing ; before statement" on top of every page, too. I usually use latest Firefox, on Windows XP machines. I use vector skin. --Jarekt (talk) 12:44, 9 January 2012 (UTC)

Files in notes

I occasionally add files to annotator notes, like in this image. I would add a note and type "[[File:Green Banks - Jansky Antena info.jpg|350px]]". However that text is saved as "[[:File:Green Banks - Jansky Antena info.jpg|350px]]", so I always have to go back to the note and manually remove : before file, by editing the whole page. Is there a way to fix that. I am used to that now but it must be very confusing to others, since usually saving does not change wikicode. --Jarekt (talk) 12:56, 9 January 2012 (UTC)

The maximum thumb size inside notes is 300px. Lupo 13:37, 9 January 2012 (UTC)
May be we can bump it to 500px? Than it would be less likely that people run into this limit. --Jarekt (talk) 17:52, 9 January 2012 (UTC)

Empty lines

At NARA 200549, I got the impression that - on each edit - the tool adds an empty line to the beginning of the file description page. --  Docu  at 17:59, 3 March 2012 (UTC)

It seems, it happened only before I moved the notes above the categories. --  Docu  at 18:03, 3 March 2012 (UTC)
Confirmed; it occurs when the page text begins with an empty line. However, I haven't yet figured out why this happens. Lupo 14:11, 5 March 2012 (UTC)
It's caused by mw:Special:Code/MediaWiki/98578. I noticed bug 12130 on my private old test install, which runs MW 1.16, too. Now, the problem is that to edit a page, ImageAnnotator gets the contents of the edit page (a URL with "&action=edit") through Ajax (XmlHttpRequest). As the name XmlHttpRequest implies, this parses the string as XML, not HTML. Normally, that shouldn't make a difference, especially since the servers still send "XHTML 1.0 Transitional", which is valid XML. But it seems that somehow the handling of leading newlines is different: if gotten though XmlHttpRequest, the value of the textbox accessed in JavaScript does include that extra newline, but if I execute the same JavaScript on an edit page opened normally in the browser, the value in JavaScript does not have the extra newline. So there is a subtle difference in parsing a document as XML (what XmlHttpRequest does) vs. parsing it as XHTML (what the browser does when loading a page normally). And that despite the page containing a valid DOCTYPE that says, for XML, that it is XHTML 1.0 Transitional. I'm investigating... Lupo 08:54, 13 March 2012 (UTC)
Got a preliminary fix for this, but I'll need to test it more before enabling it generally. For now, I just know that it solves the problem on Firefox 3.6, but I'll need to verify that it also works on other browsers, including IE6. Lupo 10:24, 13 March 2012 (UTC)

Error message

Hello,

I get an error message in many pages: Error: https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-ImageAnnotator.js&action=raw&ctype=text/javascript at line 1: Uncaught SyntaxError: Unexpected token < Thanks, Yann (talk) 10:43, 3 June 2012 (UTC)

I don't. I need more information to try to track this down.
  1. Since when? Note that ImageAnnotator has been unchanged for the last four months; it's unlikely that the cause of this is within ImageAnnotator.
  2. Here at the Commons or at some other project that happens to have ImageAnnotator installed?
  3. What browser are you using (IE, Firefox, Chrome, Safari, Opera, other)? Please include the version (e.g. IE 7, FF 3.6.27, or similar).
  4. What operating system (windows, unix, macOS, other)?
  5. Which skin (vector, monobook, other)?
  6. Please give me a link to a sample page where you get that error.
  7. What happens if you add "?debug=true" to the page URL and then reload the page? Does the error disappear, or change?
  8. What other gadgets have you enabled?
I'll do my best to try to reproduce this, and if I can, to find a fix. But if I cannot reproduce this, I cannot analyze it, and thus cannot fix it. Lupo 11:52, 3 June 2012 (UTC)

Gadget Not working

My Gadged "Image annotation" does not work anymore althogh I did't change anything on my preferences on Commons and the "Disable the image annotations. If you encountered problems with these annotations, please make sure you report them, so that we can try to fix them. " checkbox is unchecked. Any help? I cannot see image notations an dont have the button to make them anymore - tooo bad because i believe it is an important and useful tool --Wolfgang Moroder (talk) 21:22, 4 June 2012 (UTC)

Please see the section above and answer the same questions. Lupo 05:43, 5 June 2012 (UTC)
Note that it worked for another user at 04:25 UTC today. Lupo 05:48, 5 June 2012 (UTC)
Answers

1)Since a couple of weeks 2)Here at Commons I havn't tried it somwere else 3)Google Chrome 19.0.1084.52 m, 4) MS windows 7 5) MonoBook 6)It does not give an error but the button doesnt show up 7)Adding ?debug=true doesn't do anything 8) Gallerypreview,Slideshow: ZoomViewer: QInominator:RenameLink*StockPhoto*UTCLiveClock ExtraTabs2*WikiMiniAtlasThumbnail Purge, Gallery Details: Tineye tab: GoogleImages tab: HotCat: Geocoding tools: Geocoding To Do, Locate images on Google Maps:

On this Image I can see the annotations and the Image note button Thanks for your help --Wolfgang Moroder (talk) 06:38, 5 June 2012 (UTC)

Ok, and on which image can't you? If it works on some images for you but not on others, I really need an example link where it fails for you. Lupo 11:03, 5 June 2012 (UTC)
I unchecked most of the gadgets and it works again (couldn't tell you which one is responsible) Thanks a lot anyway --Wolfgang Moroder (talk) 13:11, 5 June 2012 (UTC)

Doesn't like tiffs

It isn't showing the 'Add a note' at File:Lehndorf_(Saara)_-_Zentrum.tif, File:USS_Colorado_(ACR_7).tif, File:Barno.tiff... - Platonides (talk) 17:40, 17 June 2012 (UTC)

That's right. It doesn't work for TIFFs or PDFs. It works for PNG, GIF, JPG, and SVG. Lupo 20:09, 17 June 2012 (UTC)

Image annnotation gadget again not working

Hi, again, out of a sudden, image notation gadget does non work anymore. I've tryed again to check/uncheck " Disable the image annotations. " on the gadget preferences. I reduced gadgets to a minimum but nothing helped. Ca you help me? I find Image notations extremely useful. Best regards and thank you.

P.S. It doesn't even work here--Wolfgang Moroder (talk) 14:21, 30 June 2012 (UTC)

I checked on i-pad, there it works with my same login, so it must be my computer. I deleted all navigation data(cache, cookies)!?. ImageAnnotator still does not work switching from Chrome to IE. --Wolfgang Moroder (talk) 11:14, 1 July 2012 (UTC) it's happen to me too....god damn it.--Theslboat (talk) 20:05, 7 August 2012 (UTC)

Hi, image annotator doesn't work for me. There isn't any icon present on the screen that I could click to open the tool. I've checked dozens of photos, every possible "clickable" sign/icon - nothing! I'm forced to add annotations manually by copying the script from "edit" page of any given annotated photo and then saving the changes several times in a row trying to figure the correct numerical data (the x and y numbers (pixels), position of the frame) to achieve the desired effect. That's very frustrating and time consuming. Please don't tell me I have to register. It should be available for IP's as well. Cheers. — Preceding unsigned comment added by 46.171.197.14 (talk • contribs)

It is disabled for non-logged in users. Originally, it was enabled for everyone, but it quickly turned out that we got way too much vandalism that way. Community consensus was then to have it enabled only for logged-in autoconfirmed users. Lupo 19:01, 12 October 2012 (UTC)
If your browser allows you JavaScript injection, you could try to add autoconfirmed to wgUserGroups after wgUserGroups was set and before ImageAnnotator checks it. -- Rillke(q?) 22:58, 15 October 2012 (UTC)

Village_pump#Annotations

Any idea why this is not working? --FA2010 (talk) 10:41, 15 January 2013 (UTC)

Annotate in full size view

Hi there, is there any way to annotate images in full size or nearly full size? Regards,--Flominator (talk) 08:30, 29 June 2013 (UTC)

No, sorry. The only support in the script that goes in that direction is the zoom window you get when the thumb is really a lot smaller than the full size. Lupo 14:50, 7 July 2013 (UTC)

Problem with a file

Hello,

I have a problem with the annotations on this file, there are all disabled : File:Anton Raphael Mengs, The Triumph of History over Time (Allegory of the Museum Clementinum), ceiling fresco in the Camera dei Papiri, Vatican Library, 1772 - M0tty.jpg

Can you help me ? Thanks ! --M0tty (talk) 22:20, 6 July 2013 (UTC)

They changed the way thumbnail links are constructed. Not sure if this changed with a MediaWiki version, or if it's some new image scaler (the software they use to generate the thumbnails) that now causes this. ImageAnnotator includes a number of sanity checks to make sure that an image link it sees has a plausible format. That check broke now; ImageAnnotator did see the image and its link fine, but then concluded that it wasn't the link it was looking for.
Anyway, that's fixed now, and the annotations are all back. Reload your browser's script cache to see them again. Lupo 14:54, 7 July 2013 (UTC)
A big thanks ! --M0tty (talk) 21:43, 8 July 2013 (UTC)

MediaWiki:Translate

You might want to move this message under some more specifc title as current one seems to be conflicting with the message that's used as a title for Special:Translate. 88.196.241.249 18:14, 28 July 2013 (UTC)

Too bad. Maybe whoever wrote that translation extension might want to resolve the conflict without breaking other things. I have no time for this. Lupo 08:53, 29 July 2013 (UTC)

Annotator down?

Existing annotations don't show up today (same preferences as before, Win7/Firefox/Monobook). Service down or some glitch on my side? Kaluga.2012 (talk) 11:10, 5 November 2013 (UTC)

Caused by the removal of deprecated functions. Since I have no time to scurry after this, that's the end of life of this gadget, unless someone else wants to pick up. For starters, one might try replacing all calls to the now-removed getElementsByClassName(scope, tag, className) by window.jQuery(scope).find(tag + '.' + className) (except where tag == '*', then just omit it), in both MediaWiki:Gadget-ImageAnnotator.js and MediaWiki:LAPI.js. But I have no idea if that would be sufficient. Lupo 11:39, 5 November 2013 (UTC)
That's very sad news --Rupert Pupkin (talk) 18:34, 5 November 2013 (UTC)
User:Rillke has fixed it mostly for now. Thanks a lot! Lupo 22:34, 5 November 2013 (UTC)
User:Rillke tried to fix it but while debugging User:Rillke got lost in a Firebug bug where the breakpoints inside and following from a onreadystatechange callback were not hit. When he switched to Opera Dragonfly, he then saw that Lupo already had corrected the mistake. -- Rillke(q?) 10:35, 6 November 2013 (UTC)
That's great, thank you --Rupert Pupkin (talk) 10:30, 6 November 2013 (UTC)

Disable annotations inside a node

Could you please provide a mechanism to disable annotations inside a node, like infoboxes, location maps? Or is there already one? --84.3.90.28 11:19, 17 November 2013 (UTC)

h(eight) is undefined or NaN

Hi, since today, it happened to me that when adding annotations to images, the h(eight) parameter is set to undefined or NaN. Which shrinks the box to a minimal height. You can edit the images description and fix the problem manually as a workaround. But this is new erroneous behaviour and should be fixed. [11], [12], regards --Herzi Pinki (talk) 16:32, 2 July 2014 (UTC)

@Krinkle: that one's for you. Lupo 17:09, 2 July 2014 (UTC)
This version is really broken. It doesn't display notes on thumbnails either. That's what happens if you don't test your changes. Hint: DOM Element.getElementsByClassName() is not the same as the legacy wrapper getElementByClassName you removed. I suppose the problems are due to that. Lupo 18:20, 2 July 2014 (UTC)
I don't think it has anything to do with getElementsByClassName. I tested it locally and via the console and worked. I think there might be a race condition or silly typo somewhere. I'll iterate a bit further.
@Lupo: Note that I'm just trying to improve the library by 1) migrating away from deprecated interfaces that will soon be removed, 2) making use of more centrally developed interfaces in general.
This should greatly reduce the amount of code, improve its performance and stability and make it easier to install and manage by requiring less of other MediaWiki-namespace scripts to be loaded first (and promoting it to a gadget so that it can be minified and cached much more effectively). When this gadget was first written a lot of the base level infrastructure didn't exist, but nowadays it does. You and others have done a tremendous job implementing utility methods such as those in LAPI, but I think it's fair to say the developer community around jQuery at large (which should include us) is better equipped to develop, improve performance of and maintain continuous browser compatible with these utilities. I don't expect to encounter any bugs in jQuery during this. If anything it'll by my own stupidity in doing it wrong. It would mean a lot to me if you're interested to join me in this endeavour. –Krinkletalk 19:22, 3 July 2014 (UTC)
Krinkle, I don't have the time to do any serious development here these days. If you clean up things now, and stuff breaks, you'll have to fix it yourself. And yes, the "sh" typo was the immediate reason for the bug reported here. About getElementsByClassName: previous code selected only certain node kinds with a certain class. It's been so long that I'm really not sure if that is necessary, but I think it'd be safer to use the jQuery-replacement of jQuery(scope).find(((!tag || tag === '*') ? "" : tag) + '.' + className);. Using the built-in function, it's now effectively jQuery(scope).find('.' + className);, i.e., the tag is now ignored. As I said, I'm not sure if that may not have unintended side-effects. Lupo 19:58, 3 July 2014 (UTC)

in files File:Core Banks - Osprey - 01.JPG and File:Core Banks - Osprey - 02.JPG I added an annotation and than a <gallery>File:Core Banks - Osprey - 02.JPG</gallery> section to "other versions" field. After adding the gallery annotation box stopped displaying properly. Can someone look into it? --Jarekt (talk) 17:17, 7 July 2014 (UTC)

See the section above this one. Krinkle has done something to the gadget that now makes it insert the annotation height value as "undefined". Users must now edit the image description pages and put a value there manually. I did it for one of your two images. I'm leaving the other to you. It has nothing to do with the gallery. As you're an administrator, you can try to replace "sh" with "h" in line 645 of MediaWiki:Gadget-ImageAnnotator.js and see if it fixes the problem. Users have been complaining about it and they will thank you for doing something about it. -- Asclepias (talk) 18:51, 7 July 2014 (UTC)

Obsolete globals

The line 

(skin && (skin == 'monobook' || skin == 'modern')) ? '127%' : '100%

causes Use of "skin" is deprecated. Use mw.config instead. Helder 20:02, 13 January 2015 (UTC)

This script here is not used and should be deleted. The real "image annotator" is MediaWiki:Gadget-ImageAnnotator.js, where this has been fixed. Lupo 20:29, 13 January 2015 (UTC)
OK, just to explain this weird comment: Krinkle had once started an experimental version of this, and MediaWiki talk:Gadget-ImageAnnotator.js actually was a redirect to MediaWiki talk:Gadget-ImageAnnotator-v3.js, where I then left that comment. So, what the above means, is that MediaWiki:Gadget-ImageAnnotator-v3.js was never used. And while I was writing a comment such as this one here and getting ready to clean up this mess, Krinkle already did so, including a history merge (which somehow lost my edit making the aforementioned correction in the history, but the resulting script code does still have it). So, in any case:this is fixed. Lupo 20:47, 13 January 2015 (UTC)

Unable

I'm unable to add annotation (using the annotation-script) on File:Stockholm Pride 2015 Parade by Jonatan Svensson Glad 04.JPG, while I am able to do it on almost every other image on Commons. Why? Josve05a (talk) 20:11, 16 August 2015 (UTC)

I can't get the "Add a note" below the image to appear. ALl other images are fine. Josve05a (talk) 20:16, 16 August 2015 (UTC)
It works in Firefox Nightly, but not in Mozilla/5.0 (X11; CrOS x86_64 7077.111.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.125 Safari/537.36. Josve05a (talk) 20:24, 16 August 2015 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=MediaWiki_talk:Gadget-ImageAnnotator.js/Archive01&oldid=708099980"