I could not reproduce it anymore – although I'm not totally true that I used the same setup as back then. But let's hope it got fixed already. :)

The other dependencies of the binary also seem fine (ldd):

	linux-vdso.so.1 (0x00007fff6fd7c000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2874441000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f2874239000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f287401c000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2873e05000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2873a66000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f2874876000)

Here is another example where an image is shown rotated and stretched in Mediaviewer:
https://de.wikipedia.org/wiki/Benutzer:MichaelSchoenitzer/test

I ran into this issue last year, when writing MachtSinn. Nice to see that this is actually a bug and not a design choice. Is this already deployed, so I can remove the hack I needed to circumvent this?

I would like to see the ordering being implemented and I share the doubts on the use of colors. But I want to point out that just sorting the values by rank will only solve half of this problem. It will make it easier for people to see which statements have the highest/lowest ranks – but the other (in my opinion bigger) problem is new/sporadic editors and data users often don't know about the existence of ranks and don't notice the small, hardly different, icons and therefore wrongly remove or modify data. In my opinion the ordering will likely not improve this situation.

I created some rough mookups. All icons and colors are just rough ideas and not final designs.

Can confirm that the issue seems not to appear with a brand new account. It does however occur on both, my private and my work-account. Since I don't have much customization in later it's likely to be something widespread. :/

Yes, this was on de-wikipedia: https://de.wikipedia.org/wiki/Benutzer:MichaelSchoenitzer/test

Can the note "Currently tool memory limits can only be adjusted for Grid Engine Web services (T183436)." be removed from the wiki page? Or is this still the case?

Also occurs when selecting Lexeme namespace in advanced search.

What is still needed it a way to make add the audio-player inline. That means as an icon not (much) bigger than the line hight. This is – among other use cases – desperately needed for pronunciations. This becomes even more relevant after Lingua Libre creates pronunciation files in huge quantities. Several Wikis have templates with ugly hacks for this. See T229169

In T222986#5351455, @Pamputt wrote:

Waiting that this feature be implemented, it is already possible to "delete" a pronunciation during the "Recording" step. To do so, you can simply press the "Del" button, so that the pronunciation is deleted and you can re-record it directly.
That's said, I agree that this shortcut should be documented somewhere.

Problem occurs on Firefox 66 on Ubuntu 64bit – so it's apparently not due to browser-version. Maybe an Addon? I'll try out next time.

Maybe using LDF instead of SPARQL would be an option?

In T206392#4976407, @Pintoch wrote:

What is the protocol to go forward on this? Should we hold a RFC on-wiki to let people choose among the possible solutions above?

I'm currently having a lot of things on my plate. Is this something I have to act on immediately/soonish?

By talking to other wikidata-editors and looking at other commons.css-files it seems that quite a lot of people have this issue and use CSS-Hacks to work around it, one more reason to solve it at it's core. I identified the following possible solutions:

There's a little bug with sources, but that's easy to fix.

In T153685#4810420, @Mvolz wrote:

In T153685#4810151, @Jan_Dittrich wrote:

Although this ticket actually conflicts with my own ideas about how the button should work.

We would need to review the solution/UI (separately of the code) anyway before we merge it.

I mean, that's dependant on the process being under WMDE control, but the repo is on Katie's personal github and she's no longer with WMDE (I think!) - should the repo be moved to the WMDE org?

This is fixed in my fork of CiteTool:
https://www.wikidata.org/wiki/User:MichaelSchoenitzer/CiteTool

This is fixed in my fork of CiteTool:
https://www.wikidata.org/wiki/User:MichaelSchoenitzer/CiteTool

This is fixed in my fork of CiteTool:
https://www.wikidata.org/wiki/User:MichaelSchoenitzer/CiteTool

I had the same problem and solved it by using the API with the generator exturlusage.

@Lydia_Pintscher I'm not sure if this is a duplicate of T139081. Where that ticket speaks only about the rank-selector in edit-mode, my concern is also/mostly about the rank-icon in viewing mode. If you close this ticket, you might at least integrate the additional aspects into the other ticket.

I see this as less as an alternative to the Wikidata Query Service. SPARQL has to be learned and is slow. This is more similar to ldf. But ldf still lacks a usable user interface. I hope it to fill the gap in the graph here. A fast and easy way to find things based on one to three properties with all the comport that the search provides.

Another case where this happens is this image:
https://de.wikipedia.org/wiki/Datei:Logo_PeerTube.png

resvg seems the by far most promising alternative available, it's faster, saver and renders better than librsvg in most aspects and the software-architecture seems more future-proof.
But it's also a very young project – therefore the missing debian-package – and up to now a one man project. It's therefore probably to early to switch.

I do a lot of manual editing on Wikidata specially with statements, and this never happened to me. Can you please tell me what browser are you using, so I can test it in the next edits Im doing?

Because of this I currently add statements in two edits: first only the base-statement, save this and then edit again to add the qualifiers. This (click save, wait until it's saved, click edit) is faster than typing the name of the property. When adding hundres of statements by hands this time-difference does matter (mostly in form of annoyance)! But this hack is also not ideal since a) it's still slower than it should be and b) it creates two ugly revisions in the history!

Sometimes there are even multiple of these blocks:

Thanks @Schnark!