Please disable 2-factor authentication on this account - 2016-08-15 - thanks
- User Since
- Oct 7 2014, 2:49 PM (136 w, 6 d)
- IRC Nick
- LDAP User
- MediaWiki User
Sat, May 20
Mon, May 15
Mon, May 8
Given that we removed the category in https://gerrit.wikimedia.org/r/315121, and we now have an open patch, I'm going to reopen this and move it to "Needs review" - to be shortly followed by a close assuming I like the patch.
Thu, May 4
It's currently stalled awaiting some form of Wikibase on Commons, we decided it would be better to use that for storage rather than re-write the extension after it's released.
Wed, May 3
The actual error message (based on my upload of DavidStatue.stl) is "Internal error: Server failed to store temporary file."
Tue, May 2
Taking this now, as it is a requirement for mobile support.
Thu, Apr 27
Could use some input as to the balance between the tiny number of people who use this field for a specific purpose that would be useful to readers on other wikis, compared to the tiny number of people who are confused by the field as it is...not sure where we stand on this. Lowering priority due to small impact on both sides.
AFAICT, whatever I was smoking then has gone out of style, and we have mw.Title.newFromImg() which should obviate this issue? Anyway, I don't think we need this.
This should be as simple as removing the class file and replacing wherever the constructor is called with a simple object with the correct properties.
I'm leaving this stalled until structured data is available to clear up the authorship questions present, even in the file you listed as an example. The current structure of the license template and attribution value above are not conducive to us solving this in a good way.
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.
I agree that we don't want to potentially hurt the credit on most files for a tiny use case - and I agree that we should try to fix this once structured data makes it easier for us to credit creators. Leaving stalled, but we definitely want to fix this as soon as is practicable.
Based on the long gap between responses on this bug, I'm going to guess that it's no longer an issue - especially since seemingly none of the examples still cause problems (at least for me).
Tue, Apr 25
Should review and improve patch fairly soon.
This can probably be worked on pretty soon.
This is worthwhile, but it's something that will require a lot of looking into the necessity of various dependencies, and bits of code. Hopefully we can schedule this for sometime soon, but unclear exactly when.
This is not a media viewer ticket, reassigning to a more useful project...still something we should look at, though.
This should probably happen after we implement licenses in structured data.
Apr 20 2017
I also cannot reproduce. Given that there is not sufficient information to reproduce or investigate further, I will close this bug - if someone comes back and reopens it, please include more information about your browser and other configuration details so we can actually look into this.
I think this doesn't rise to the level of "normal", as it's a totally optional feature request that would only affect a pretty small subset of files and users...something to think about in the future, but not something we need to rush towards.
I fear the initial triage and investigation may have missed the point of this bug - @Steakyfask1 are you saying that, after exiting the Media Viewer, the scrollbar for the article is disabled? If so, can you please tell us what browser you're using? I could not reproduce this on English Wikipedia with Google Chrome on Linux.
Coming back to MMV bugs after some significant amount of time, I have to agree with @Tgr that, while this may make it harder to test the extension alongside other extensions, it is absolutely true that the tests' assumptions are mistaken. As this is only within the MediaWiki-extensions-MultimediaViewer project, I'm going to lower the priority on this once again and move it to a holding pen on our workboard. If the maintainers of the Cite extension want to take over this task and alter how their tests work, I would be happy to see an increase in priority.
Apr 19 2017
@Ineuw do you want a totally new interface that detects redlinked categories after upload, and offers an option to create a page for them? It's not totally clear the scope of this request, but if you can clarify, I'd be happy to talk with someone about what it would entail.
Apr 18 2017
Updated patch, @Jdlrobson if you want to take another look that would be nice
@Prtksxna would it be sufficient to add role=button et al. to make these accessible in the usual way? It's not clear what specific issue you're looking to solve.
Apr 13 2017
Yeah, that project is long gone.
Mar 28 2017
Mar 26 2017
Mar 10 2017
Mar 7 2017
T159884 maybe a use case for this at some point (mentioning for bookkeeping)
I sent an e-mail to the ops list to ask for some help coming to a resolution on that. I'll post here with a description, along with other tasks if necessary.
Mar 6 2017
Blocked on T157077, will go forward once that's closed.
Mar 5 2017
Mar 1 2017
Feb 28 2017
Feb 27 2017
Fixing thumbnail process, the wgMaxShellMemory was too restrictive
D580 should fix these concerns, but I skipped a couple as noted in the commit message.
Feb 19 2017
Feb 14 2017
Feb 10 2017
I suspect this is mostly a problem with the server timing out or being overloaded with the 40mb file that James tested with - we will test aggressively with big files on the beta cluster and see if this remains an issue.
Cool. I'll delay this for now, then.
Correct, but as above, if the thumbnail has a different aspect ratio from the viewer, there will be a significant visual jump...though I suppose I could try and see if it affects anything. I expect there may also be a problem with the rotation not being perfectly aligned with one axis or another (so the thumbnail will also potentially cut out bits of the object) but it may be unfounded. Ugh, I will try investigating. I'd almost rather not have the viewer and thumbnail codes diverge so much (as the dimension/view code is basically identical right now), but if this is a big deal then I can.
I was just mucking around with this, and a friend made an accurate observation that, if we have the thumbnail for e.g. a 1x100 aspect object, be a 1x100 thumbnail (or maybe with some padding, 3x102 or whatever), then when a user rotates in the viewer, they will only see 3/100 of the object. We could fix this by using the entire bounding box, and setting it to a square-ish thumbnail with the greatest dimension setting the value, but square aspect rations tend to squash the object a bit (compared to e.g. Thingiverse's rendering). However, if we only did it to the viewer (i.e. not to the thumbnail), we would see a significant visual jump as the viewer loads in Media Viewer.
Feb 8 2017
@Miriya52 I have the same answer as above.
Feb 7 2017
Feb 6 2017
@Legoktm yeah, I think @Gilles probably figured we'd be in Diffusion by the time it got deployed. We can move it into Gerrit whenever that's needed, and if there's any information set up for that, that would help me.
Turns out this is already the case, but the grab/grabbing cursor values aren't supported in webkit or mozilla yet. Adding compat rules (and "move" fallback) in a new patch...
Feb 2 2017
Jan 31 2017
OK, I'll leave this up to @Jdforrester-WMF to decide when he returns to keyboard.
Jan 30 2017
As far as I understand, the 3D extension currently has these capabilities, at least in part. See rTDTP for the thumbnailer, and https://www.mediawiki.org/wiki/Extension:3d for the extension (with thumbnailing and Media Viewer support).