https://bugzilla.wikimedia.org/show_bug.cgi?id=54035
Tisza Gergő <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #6 from Tisza Gergő <[email protected]> --- (In reply to Brad Jorsch from comment #5) > I see no reason for this to be not only wikitext-like but > actually be exactly what's used in the image syntax, if at all possible. The > only difficulty might be if any media handler needs multiple image-syntax > parameters to fully characterize the thumbnail. All media handlers which take nontrivial parameters need that: the size will be one parameter, and all else (page number, quality, language etc) > We already have too many image-related prop modules, IMO: imageinfo, > videoinfo, and stashimageinfo all do basically the same thing, just for > slightly different cases. I don't see why multiple image-related modules would be a problem. We have half a dozen link-related modules; it's actually a lot less problematic than stuffing all the functionality in a single module. If anything, imageinfo should split up further IMO. (As a matter of fact, I would like to split out extmetadata into a separate module, with significant changes. I hope to put up an RfC about that in a couple days.) The problem with imageinfo/videoinfo/stashimageinfo is that they are split the wrong way: instead of providing different functionality for the same file they provide the same functionality for different file types. > I like option 4: Deprecate prop=imageinfo entirely in favor of something > that isn't so full of warts. Details at > https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Rewrite_prop. > 3Dimageinfo_from_scratch_as_prop.3Dfileinfo > > Although my proposal there includes option 2 when it comes to thumbnails. > > Fleshing out that proposal and even help with coding it would be very > welcome. The proposal sounds good but also sounds like a long-term thing. It would be nice to have a solution for the single-size-per-request limitation right now, MediaViewer development is inconvenienced by it. If I understand correctly, code written for option 2 could be reused when implementing option 4, so going with that option now would not be wasted effort, right? (As a side note, my dream API would have JSON instead of string inputs so that attributes can be set per-file instead of globally; in the case of thumbnail URLs, this would lift the current limitation that the same thumbnail size(es) have to be returned for all files (and all revisions of them). Something like [{ "title": "File:Foo.jpg", thumbs: [ { width: 220px }, { width: 640px } ] }, { "title": "File:Bar.jpg", thumbs: [ { revision: 123456, width: 100px } ] }] would make more sense to me. Consider an interface similar to the file page, with a large image of the current revision and small images of the old ones, or a collection interface like [1] - wanting different sizes for different images / different revisions is a fairly natural use case.) [1] https://www.mediawiki.org/w/index.php?title=File:Media_viewer_designs_-_media_support.pdf&page=3 -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
