I was trying to see my contribution (here) and the Emanuele676's ones (here). The pages took a long time to load, so I tried to reload the page with the Firefox browser reload button multiple times for both pages. Sometimes it appeared an error like the one at the top, sometimes the page finished to load half styled and without graphs, and (but I don't think that this info is useful) I seem to remember that the legend was present. Soon after I finished writing the message above it seemed like everything went back to normal.

In T384711#10849469, @MusikAnimal wrote:

In T384711#10849464, @zdev wrote:

Now it seems to be very laggy and in the page returned, if it does not emit directly an error, the graphs are not loaded.

Vital signs look okay and things seem to be running normally for me.

Could you file a separate task and give more details, including links?

In T384711#10849464, @zdev wrote:

Now it seems to be very laggy and in the page returned, if it does not emit directly an error, the graphs are not loaded.

Now it seems to be very laggy and in the page returned, if it does not emit directly an error, the graphs are not loaded.

I think this happened to me also two days ago on it:Aiuto:Sportello informazioni, further messing up an already complex situation.

Dream and hope (sogna e spera). I think this will not ever be done.

The hover tooltips are being added with T388977: Display values on hover on pie chart slices.

In T266155#9766334, @Bawolff wrote:

I think if we did deliver the wrong thumbsize, it only makes sense to deliver one larger then the requested size. Browsers will scale it client side, and its always better to downscale then upscale. The performance degredation is probably be not that bad - the larger thumbs would only be shown to first person to view the page. A small slowdown to image viewing for a single user seems not that bad, and better then never loading the image at all.

I think the biggest problem is that it is very unclear how feasible this would be to implement on varnish side.

Maybe an alternative solution would be to have client side detect and try and re-request, although in the case of overload that might just make things worse

I linked mw:Help:Printing to this ticket. It was already mentioned that this feature was deprecated but there was an info like "It appears a warning box". I also specified that it the future it will be removed.

I linked mw:Help:Printing to this ticket. It was already mentioned that this feature was deprecated but there was an info like "It appears a warning box".

Also the recommended media queries in mw:Recommendations for night mode compatibility on Wikimedia wikis generates two warnings of this type, see:

In T368637: Allow use of CSS `var()` for CSS `border` in css-sanitizer it was asked why the sanitizer cannot accept a border-color rule with only a single var(...) as its value.

Yes I've seen it but it seems that a temporary solution is taking too long and is becoming permanent (and it is in good company...).

In T388990#10639207, @Peachey88 wrote:

Can you explain how we could actually improve the page? For example a TOC with all the projects listed?

Updates? I don't think that this extension is "maintained" as the future is precarious and nebulous.

Yeah I'll support it. But consider that newbies are probably not aware of the complexities, deformities, counterintuitiveness and peculiarities behind copyright rules.

In T28741#10541452, @Ladsgroup wrote:

In T28741#10541414, @VirginiaPoundstone wrote:

@Ladsgroup do you have a timeline for this migration?

It depends on how fast the migration script will go. Since we are waiting for text table migration to finish before starting image table migration on commons. I think the data will be migrated in two months.

I suggest writing the code behind a feature flag and ready to flip the switch once the migration of data is done since we can't wait long with both data schema in place.

For most other wikis, the data migration is done already.

Could it be related to T382699: Page Deletion Fatal exception of type "Wikimedia\Rdbms\DBQueryError" due to lock timeout and its subtask T385809: Protect page actions with advisory locks?

In T381906#10413571, @Pppery wrote:

I don't like how much I feel like I'm the only person keeping this project from collapsing into a tide of chaos, but fine.

Is there a timeframe on when the LQT->Flow conversion script is likely to be done?

The Flow extension, now StructuredDiscussion is now unmaintained and is being undeployed from Wikimedia wikis (see T332022: [Epic] Undeploying StructuredDiscussions (Flow)).

In T106240#10250074, @Chealer wrote:

Side note about color accuracy

I noticed while sorting all our check mark variants that the color of some PNG conversions are slightly incorrect. The body of the check mark in the SVG has a color different from the body in the PNG, although the difference is hard to notice from naked eye. Cases I noticed:

1. Green_check.svg, which has #088908 instead of the specified #118811.
2. Check-green.svg, which has #008100 instead of the specified #008000.

Purging the cache does not fix. If someone is aware of this bug, please let me know if it is tracked.

In T388050#10608106, @Dylsss wrote:

I can reproduce on all wikis but you have to start out in visual editing and then switch to wikitext editing. Somehow the action of switching the editor seems to remove the message altogether.

Maybe it happes only in it.wiki? I asked in WP:Officina.

https://wikipedialibrary.wmflabs.org/partners/166/

• https://wikipedialibrary.wmflabs.org/partners/56/ (Emerald Group Publishing)
• https://wikipedialibrary.wmflabs.org/partners/78/ (ICE Publishing)

Is there any trace of this resource somewhere?

https://wikipedialibrary.wmflabs.org/partners/150/

https://wikipedialibrary.wmflabs.org/partners/143/

• https://wikipedialibrary.wmflabs.org/partners/152/ (Haaretz English)
• https://wikipedialibrary.wmflabs.org/partners/153/ (Haaretz Hebrew)
• https://wikipedialibrary.wmflabs.org/partners/154/ (TheMarker)

https://wikipedialibrary.wmflabs.org/partners/155/

https://wikipedialibrary.wmflabs.org/partners/148/

https://wikipedialibrary.wmflabs.org/partners/149/

https://wikipedialibrary.wmflabs.org/partners/146/