|mediawiki/extensions/CommonsMetadata : master||Parse annotations|
|Open||None||T133526 Epic saga: immersive hypermedia (Myst for Wikipedia)|
|Open||None||T58666 Show file annotations in MediaViewer|
- Mentioned In
- T214405: Designing for structured Image Annotations
T145453: FileAnnotator should not append itself to <body>
T145450: Separate FileAnnotator class from code in fileannotations.js that should run on page load
T108887: Nice UI for image annotations
T76886: Investigate computer vision image classification and description tools for shadow tags and search descriptions
- Mentioned Here
- T108887: Nice UI for image annotations
Aalekh, I'm not sure what you mean by annotation. The caption will show up in the image information, but annotations are associated with some sub-area of the image, and there is no good way to specify that in a caption.
I worry this might be unnecessarily complicating the extension. Just because we can doesn't mean we should...
What are the benefits of doing this and what are the risks? What does it enable? Can you give some examples of some concrete use cases?
More code means more maintenance and adding expectations around what the feature can do. "It would be nice" doesn't seem like a good motivation, let's understand this more before pushing ahead and merging the patch.
MediaViewer tries to support all the useful reader-facing functionality of file pages that's accessible in a structured form, and annotations are one major missing piece. The link in the task description documents a lot of existing use cases; I don't think those would be fundamentally changed just because we show them in a lightbox instead of on the file page.
Note that the patch is to CommonsMetadata and just exposes the annotations as (somewhat) structured data. The benefit to that, apart from making annotation support in MediaViewer possible, is performance - a few wikis show annotations on article thumbnails, and to do that they now request the file page of each thumbnail in AJAX and process it, which excruciatingly slow. The API can serve metadata for a large number of files in one request and it can do most of the parsing on server side, which is then cached.
In case the question about benefits was serious, I'll try an answer:
- Raise the mediaviewer's level of encyclopedic value to bring it on par with the projects it serves.
- Preserve the knowledge and work of many editors who have explained images via annotations.
- Reduce editors' level of frustration with WMF.
Hmm, the line you refer to also continued with "Can you give some examples of some concrete use cases?" (emphasis by me).
The terms "encyclopedic value" and "on par" probably need elaboration to make them less subjective.
Knowledge is preserved (as it's not deleted). But it is currently not displayed and harder to find. And that's what this task is about.
High-level issues like "editors' frustration with WMF" won't change by fixing a bug report and should go to the appropriate mailing lists or wiki talk pages instead. Thanks! :)
We won't be working on file annotations until we can store them in structured data, so this work is going to wait for a bit. You could work on this based on the current implementation of FileAnnotations, but I wouldn't recommend it, as the implementation will change.