Jan 6 2021
Aaaahm I did only say "2. Check the first two entries" :) Forgot to say that there need about 5 in the list
I reopen it as I was able to reproduce it with two browsers
Reproduced with the Edge:
Jan 5 2021
Note that also a simple refresh (F5) does not reset the checkboxes. I need Ctrl + F5 to reload the page without cache.
Sep 30 2020
Aug 11 2020
Apr 1 2020
It had cost much edits and time on discussion pages to find the real problem. Since the authors invest their time voluntarily, they should not waste it. So I think it's a good idea to learn from the problem and use the gained experience in the automated checks of the upload wizard by adding an additional check that makes it clear even to the inexperienced user that this is not a real SVG file.
Oh that was from my clipboard not for this task :)
First, there are problems which blocks the upload of this file but it's correct that this file is being blocked.
Please just try to upload this picture and you'll see a warning that blocks the upload because there is a dangerous href link in the SVG. The warning is correct but the problem behind isn't called. The problem is that the "normal" user will think he exported a "real" SVG from his programm. Open the attached file in the text editor and you'll see that this SVG is no SVG it's a PNG embedded into a XML structure. This is not what the user wants, because he wanted to upload a "real" SVG file. So it would be a great help for such users to be noticed with a better warning than the "dangerous href link"-warning. A warning that says "Guy, this is not a real SVG, it's an embedded PNG."
That's not a bug, it's simply a feature request to check if the SVG file is an embedded PNG. I uploaded a file for you with a PNG embedded into a SVG.
Mar 31 2020
Feb 10 2020
Feb 9 2020
No problems since weeks ago
Feb 5 2020
Ok you're right, I thought it's the same backend architecture then TOTP. Will do it better next time :)
After iterating trough the process multiple times I realized that Webauthn doesn't work crosswiki. It work's only in the same wiki I registered the key.
Jan 31 2020
@Ladsgroup thank you for this extended description about the "why". I can understand and accept, the decision. I agree with you that it is not worth to spend 1 month of work into it, there are many other topics which are more useful to invest time into.
Jan 18 2020
Jan 16 2020
@Aklapper please step away from this excessive behavior with admin rights. You don't want this, we already noticed that but stop blocking our opinions and ideas without a valid reason!
I would like to reopen this task and discuss pros and contras
Jan 11 2020
Jan 10 2020
Please see T242465 for an example case. You know I am not alone, you closed the Task as duplicate of T229064. Please see also T44085#5127606. There are cases and they are described in the Tasks that were closed.
@Legoktm I also cannot find any discussion for that.
Unused links could not be reused like described in T242465 but as you showed me it seems not welcome to have custom shortURLs.
I didn't knew how to link meaningfully to T242465, then I forgot it... There are cases where I just need the shortURL for one or two guys in single use to tell them the URL via telephone. Such links aren't needed to live forever but others may like to have w.wiki/HB for a permanent solution like the example in T242465.
Another solution is a checkbox "Delete when not called for <number-of-days> days".
Dec 5 2019
Nov 26 2019
Nov 24 2019
See also: T239018 (Request for removing the whole trending-section from dewiki app)
Nov 19 2019
Well, most vocal people are the ones who have the power in a democracy :)
@Aklapper Originally I wanted to wait until the current poll on dewiki is finished. The currently running survey on dewiki shows a clear aversion to the whole "beliebt" (popular) section in the app. They want to see the feature hanging!
Instead of waiting for the result, because you're dragging me to act, I close the task as rejected (by the community).
Nov 17 2019
Oh sorry: yeah it's a feature request for the parent task for all sites, specially for spenden.wikimedia.org where I saw it. My uncle donated and with 65 years he had large problems with filling the fields.
Didn't wrote it cause I didn't saw it here before to mark proposals as proposals.
Nov 16 2019
@MusikAnimal, that's what we can see since month:
Nov 15 2019
Version was unreviewed and reviewed again
Nov 9 2019
An additional idea: If the captcha wasn't entered correctly you can skip it without counting the request
Nov 6 2019
Yeah, the magic word is "sometimes" for me. Of course a few techies will still love it to read the articles via API but what we want to show the other users on the main page is not those requests. We wanna show which articles are interesting the society. So I think that's not an argument and we can neglect this <0.00001% case (not counting the requests via api).
You can still run curl or wget but you'll be limited to 50 requests (if you request the same lemma again and again). But why should you do that in one hour as "normal" user? And let's suppose that you have such a case then it's not a "normal" user case and if you want to do more than 50 requests nobody will stop you if you use ?robot=true but then it's a non-human case and we wanna show which articles are interesting the society.
Nov 4 2019
See also T232992#5632739. It is important!
That's why I suggested 2 month :)
@Aklapper maybe we don't have the same scope with "API".
The first solution is to allow access only via api-token but that's not in that what wikipedia stands for so I would just count human HTTP requests and the API is exepted from the most-viewed counter and the captcha.
Nov 3 2019
I need to reopen the task as I see that the articles are still on top of most viewed articles. It doesn't help to remove falst traffic, we need either to remove these articles from the index or removing this whole list to combat against it. If the articles are removed from index Mr. Sammet and co. have no chance to get into it if they would become famous so I propose a time-based "ban" of maybe 2 Month.
Oct 18 2019
Oct 17 2019
Please try to use this task only for task-specific information. You can answer me on the (your) linked user talk page.
If you want to code, see here (you can change the language) and here.
We use Gerrit to review code, the git origin is also on gerrit: https://www.mediawiki.org/wiki/Gerrit/Tutorial
@75pollet as I see you are new here, i'll write you on https://meta.wikimedia.org/wiki/User_talk:75pollet
Oct 5 2019
Sep 30 2019
Aha found it! The original MP4-file was larger than 10MB (see T94564) If the file is larger than 10MB it fails with "No configured storage" instead of "File too big"... So after converting it from MP4 to webm and back to MP4 it doesn't look so nice now :(
@Charlotte is it possible to upload the Video here on Phab? I think that would be better than on commons (also licensing)
Sep 28 2019
Sep 26 2019
Many thanks for the detailed answer, I had not expected that at all. Yes, I can already imagine that with 20 billion questions a day there would be several hundred thousand errors so filtering this is difficult. It did not let me go and I thought about it further. So another idea: Wouldn't it be realistic to extend selected APIs (e.g. everything that has to do with editing, where errors are critical for the user) in such a way that they output an error ID under which they store the error information centrally for a certain time (e.g. 30d)?
Sep 19 2019
Aug 23 2019
Ah okay and that's obviously disabled I understand.
A stupid question: Are there any techniques implemented to synchronize replications or to report faulty replications? This will not be the only error. As I read you got all this information from logs as textfiles...
Jul 4 2019
I set a new priority because the risk is moderate but the impact is disastrous. Hours of work gone.
Jul 3 2019
Same problem, again and again. Not reproducable, happens randomized.
Jun 26 2019
Jun 25 2019
Thank you, perfect, thats correct.
It's about the VisualEditor :)
Jun 18 2019
May 21 2019
Okay, thank you! So I'm not alone.
May 18 2019
Just wanna ask if you could explain me the current status. I currently stuck on this problem while editing :)
May 7 2019
Sorry I don't know, I'm just reporting the 404 :)
May 4 2019
Apr 20 2019
Server works now.
Apr 19 2019
I also tried to telephone to WMDE but they aren't at work so maybe smb. knows the phone number of their IT.
Apr 5 2019
Mar 19 2019
Oh yeah, I hate the problem described in T212554... Here we have the problem exactly the other way round (but with the table of contents).