In T218492#7661210, @EAkinloose wrote:

and https://photos.app.goo.gl/vNqmrq4Dyy7kHG2K

@EAkinloose that looks for me as user like I would expect it. 👍

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:

Note that also a simple refresh (F5) does not reset the checkboxes. I need Ctrl + F5 to reload the page without cache.

In T208981#6503749, @matmarex wrote:

@Der_Keks If you still remember this issue you filed two years ago… Please try out the new workflow on the beta cluster (e.g. https://en.wikipedia.beta.wmflabs.org/wiki/Reused_references) :)

In T244348#6373129, @FozzieHey wrote:

I think the majority of users will only have one.

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."

<s>Wrong template...</s>
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.

No problems since weeks ago

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.

@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.

In T229064#5811461, @Aklapper wrote:

Hmm, what does this proposal have to do with Accessibility?

@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

In T242464#5793969, @Aklapper wrote:

I have seen T242465, I just don't understand how it is related to this task.

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".

I refer to T238942#5715768, another article seems affected. The discussion is on the admin noticeboard.

See also: T239018 (Request for removing the whole trending-section from dewiki app)

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).

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.

@MusikAnimal, that's what we can see since month:

Version was unreviewed and reviewed again

See also https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Umgang_mit_der_Anzeige_von_beliebten_Artikeln

An additional idea: If the captcha wasn't entered correctly you can skip it without counting the request

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.

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.

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.

In T233331#5586260, @matmarex wrote:

I think we don't show them more widely because usually there is just nothing logged there.

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

In T234122#5534749, @Charlotte wrote:

@Der_Keks - It seems like that particular filetype is not supported. Perhaps upload as an MP4?

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 :(

Upload Failure
20190928-phab-bugreport.webm

@Charlotte is it possible to upload the Video here on Phab? I think that would be better than on commons (also licensing)

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)?

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...

I set a new priority because the risk is moderate but the impact is disastrous. Hours of work gone.

Same problem, again and again. Not reproducable, happens randomized.

Thank you, perfect, thats correct.
It's about the VisualEditor :)

Okay, thank you! So I'm not alone.

Just wanna ask if you could explain me the current status. I currently stuck on this problem while editing :)

Sorry I don't know, I'm just reporting the 404 :)

Server works now.

In T221456#5125456, @Reedy wrote:

In T221456#5125392, @Der_Keks wrote:

I also tried to telephone to WMDE but they aren't at work so maybe smb. knows the phone number of their IT.

Friday 19th April is a National Holiday in Germany it seems (Good Friday, as it is in many other countries), so not really a surprise WMDE aren't open

I also tried to telephone to WMDE but they aren't at work so maybe smb. knows the phone number of their IT.