@Tgr btw. Regarding our wikimania conversation, I was referring to T32961

There are infinite sizes, so 'all sizes' doesn't exist to begin with.

PrintPdf isn't any different than any other print. So this isn't really PDF specific but more print in general.

@Krinkle and @Jdlrobson I did some testing and I was able to force Safari to load the native lazy images, using a onbeforeprint handler and setting the loading property of each img to 'eager'. I can also just remove the loading attribute and this too seems to load the images. I had tried this in the past and it wasn't working back then., so possibly some improvements have been made by Apple.

Quite possibly a regression due to the temporary accounts refactoring, so adding that project.

many files with weird wikitext.

Yes, this is impossible to do 100% correctly without Commons Data. parsing wikitext will always have failures.

Discussed this with @Ladsgroup
We concluded that this is simply not really worth the effort in the this patch round. As Wikimedia doesn't rely on it, rearchitecting the testcases of Wikimedia to not so strongly depend on searchindex will needlessly complicate things. Instead, I'll provide maintenance script to convert to innodb for those who desire this.

Note: we don't have any of the mirroring info in our metadata tables, as we actively turn it into jepgRotation (with a value in degrees). So retroactively figuring this out for all images, requires reparsing all images, which is an known impossible issue...

We've been trying to determine what "Wikimedia has switched from osm2pgsql to imposm3, support for more relation types can be configured, now type=waterway is supported in addition to previous three types. It should be further reviewed which other relation types can be and should be supported." actually means.

Reminder: todo rewrite the modules to make use of RL's config.json logic / virtual files provided by PHP, instead of using our own config object.

In T363885#10053854, @tstarling wrote:

In T363885#10051120, @TheDJ wrote:

Any ideas ?

I don't know why it would work in the src dir. The find module is documented as setting JPEG_INCLUDE_DIRS which should then be passed to target_include_directories(), it shouldn't just work by magic.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/3D/+/1061039

In T371621#10042785, @MarkTraceur wrote:

If @TheDJ is correct then this is likely not an issue on the Structured Content team/MediaSearch extension side, right?

@tstarling I tried compiling on my mac, and i'm glad to report that it works.

In T367463#10021736, @Theklan wrote:

I see that this is still happening here: https://eu.wikipedia.org/wiki/Wikipedia:Bost_euskarriak. What should we do to improve that? Should we find every affected page and solve it manually?

In T117618#10043609, @Vollbracht wrote:

What's the effect? Shall Wikimedia content be include-able into Commons svg graphics? Are we talking about resources external to a given svg graphic or external to Wikimedia?

Traditionally...

• the vast majority of Wikimedia video material is in English
• english wikipedia has a large international non-native speaking audience
• subtitles for Wikimedia videos (especially in your own language) are actually pretty rare.

To facilitate and encourage discovery of subtitles, they are enabled by default when available in your language.

Community: Go left, no RIIIGHT, no middle !!!

In T369499#10037164, @Pcoombe wrote:

I think the "Never" option dates from when some skins had links underlined by default: the long-since removed classic and the long-since deprecated Cologne Blue. So it made sense to have an option to override that.

As the cause of this seems covered by T360913 and the incident as reported was resolved, i'm closing this.

This is a pretty common exception, nothing new, not a blocker: https://logstash.wikimedia.org/goto/8d2eb4f8c362a150b5819e17602fda7d

@Tsarivan613 I purged the page, and this regenerated the thumbnails and now it works.

Related logical properties tickets: T322482, T304017

Documented at: https://www.mediawiki.org/wiki/Help:Magic_words#Localization

In T371383#10030667, @RolandUnger wrote:

I do not think so. dewikivoyage uses the same Parsoid (0.20.0-a14) and Kartographer versions (4b02f48, 22 July 2024) like enwikivoyage.

In T224922#10030073, @Pppery wrote:

The Book Creator has not been disabled anywhere. It's been hidden from the sidebar, but still works if you know about it I think. But that, and the decision to delete the book namespace, were both much more hard-fought than you think.

And there's also https://mediawiki2latex.wmcloud.org/

I personally think the entire collection extension should be undeployed and archived at this point. But it appears that at least some segment of the community still sees value in it, as comments like https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_177#c-Steelpillow-2021-03-16T17:35:00.000Z-Aza24-2021-03-13T06:48:00.000Z show.

• The book creator is disabled from some of the biggest wikipedia's: dewiki, enwiki, fawiki, fiwiki, nowiki, ruwiki
• it hasn't been maintained since around 2014
• the ui has references to downloads all over the place, but these downloads are not actually being provided for books. All downloads are done via Electron/Proton
• it uses jquery ui
• the JS style is very old and has lots of inline JS
• it doesn't support dark mode

In T371377#10029926, @Jdlrobson wrote:

This seems strange... are we just pretending that anon users can provide feedback ? Or are we accidentally adding that element when we shouldnt be ?

We were supposed to be logging events on every click, and then the idea was to provide summaries of that data to the community.
However, as we started working on generating these reports in T370233 we discovered a bug (T371325) which meant this isn't working so we're currently in the process of re-evaluation (T370825).
We want anons to provide feedback but there are concerns (not mine) that if we push them to the talk page, we'll get a lot of spam/useless reports from IP users.

@Jdlrobson was looking at this, and there is more going on here that i do not understand...

@taavi anything left to do here, or shall we resolve the ticket ?

Noresize is a bit of a workaround, but there theoretically can be lots of elements inside a thumbnail. Adding every element possible seems like it might not scale, but i think adding it for video might be warranted.

In T306232#10021071, @Tacsipacsi wrote:

But it’s possible to add a query or path parameter to it that accepts a revision ID, isn’t it? It may require quite some work, of course (I don’t know how it works), I’m only talking about the possibility. (If it takes a lot of work, merging your patch as a short-term solution probably makes sense, but I hope it won’t be the long-term solution.)

In T306232#10021059, @Tacsipacsi wrote:

From the patch commit message:

Remove Download as PDF link on old revisions, as Electron/Proton do
not support it. […]

Couldn’t they be made support it? The merged-in task T370740 highlighted that download as PDF is broken on FlaggedRevs wikis if and only if the current page has unreviewed changes.

Btw. I figured that this might be resource intensive to calculate for all files, but I realized that the sha256’s are already in swift. So should be relatively easy to backfill one day.

I agree as well but there are some provenance issues:

• a common id is/should? generally only used when it is defined in core
• renaming this will cause the translation strings to move (should check if there are a lot of local overrides of these string perhaps)

So.. it's been a couple of years.. Any thoughts ?

That definitely is quite strange...

Thank you for the patch @Func !

In T365806#9874173, @Ioaxxere wrote:

Why can't the entire text be rendered at load time? As long as the browser doesn't run out of memory and crash, it should work fine. I would personally find infinite scroll annoying if for example I were reading Wikisource on an unstable connection.

In T362831#10000457, @hinnk wrote:

Is this issue being prioritized at all?

In T191156#9009174, @Matthiasb wrote:

In sports we have an old wisdom: never change a winning game. So was there a real reason to begin meddling with that? I mean a true real reason?

So this happens because https://www.mediawiki.org/wiki/API:Info returns urls that do not take into account the mobile domain.
I also think there is no way for it to do that at the moment.

This was fixed as part of T208564

Yes this was a pretty common problem where quite regularly floating content would bleed into the skin over the past 20 years. There was no consistency in skins that dealt with this universally, and quite often it made assumptions about where content could appear. I remember especially this being a problem in the edit/preview screen, where the previewed content would overlap into the edit screen.

In T369499#9987538, @CCiufo-WMF wrote:

We think it might be better served as a gadget rather than a feature baked into the skin.

In T369499#9987018, @gerritbot wrote:

Change #1054627 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Drop support for underline links

https://gerrit.wikimedia.org/r/1054627

In T257652#9986048, @Forza1000 wrote:

It is true that AVIF encoding is much slower than earlier formats. If this is too CPU heavy to achieve during upload, it might be possible to use a maintenance script that generates new thumbnails in avif format during off-peak hours - perhaps even Imaginary or similar tools on other servers. The gain in bandwidth could be substantial, especially for image heavy sites like Wikimedia Commons.

Here are some examples Netflix did 2020. The examples anf comparisons are a bit down the article. https://netflixtechblog.com/avif-for-next-generation-image-coding-b1d75675fe4

This is currently blocked on all our testcases relying on tables to be cloneable, but innoDB cannot create a TEMPORARY table of a table that has a FULLTEXT index.

You know... if we used wiki's instead of google docs... then half completed drafts would still be useful :)

This made me realise. Do users actually expect the left side is Next action and the right side is Previous ? Are we the exception to everything else or not ?

@Soda btw. should we perhaps set the default for WMF to false, and then flip the default for MW core to true ? I think it is good to have features like this enabled by default for new installs, otherwise most MW installs will never use them.

In T369659#9968307, @Ebrahim wrote:

So I imagine one of the following solutions,

• To not use ::after for icons themselves and partially revert the mentioned change (more plausible solution I guess)
• Add a dir attribute to next and previous icons (and stripe and dialog icons also apparently) so the first line of the CSS can match them at least
• Apply the following that only fixes it for next and previous icons,

I think I have some time this weekend to fix it.

Looked into the table/flex problem a bit.

Tagging web team for visibility. I personally think this is worth it (with fallback margins). I'd actually would very much like to use more of the logical properties, but 97% is I think just a tad too large a group of users to rely on it solely without fallback to commit to it. Especially the fact that Safari only started fully supporting in Safari 15, is problematic, as we have plenty of users with 6 - 7 year old iPads and iPhones.

That is amazing work @Nux, thank you so much!

@Jdlrobson This override also breaks quite a few infobox and navboxes, because for those we reset the background to black. so you get black on black. Perhaps these overrides need to be limited to wikitables ?