A couple of comments from a subtask that I think should continue here:

Hey @Milimetric I did see it, I had to collect my thoughts. We should probably continue discussion on T215858: Plan a replacement for wiki replicas that is better suited to typical OLAP use cases than the MediaWiki OLTP schema about this if it isn't something that is going to help this task in the short term.

I'm not sure if something like this would be in scope for Toolhub. Maybe @bd808 or @srishakatux can look at this and consider it?

I've made this task as the POC for feedback, since I'm posting an item to tech news. Any other feedback is also welcome.

In T268240#6637193, @Huji wrote:

That is a fair point. The one caveat is for projects (like fawiki) that have been doing this for a while, you can expect them to deal with all historical cases before the DB Redesign happens, and then only do it for "recently uploaded files" going forward. But for projects that have never done this, if their very first attempt at this is after the DB Redesign happens, they will have a hard time pulling that off (the script needs to check a very large number of files by running a large number of queries).

From the upcoming WikiReplicas architecture changes we have cataloged T267992, T268240 & T268242 all related to matching file pages and the image name, sha1, and timestamp between wikis and commons, and wikis themselves. This is something that is very hard to do without cross-db joins, mainly because of common's DB size and entries.

Summary of current explorations:

Very similar too to his other task T268242: Provide a mechanism for detecting duplicate files in enwiki and another wikipedia. I've commented over there.

Hey @Huji thanks for opening the tasks about your use case.

I think I may have missed that detail too.

I'll try to put this together in PAWS to see it all together, I'm not great at python and I'm new to PAWS so it may take me a bit tho.

@Green_Cardamom Maybe like @Bstorm suggested you could query for new/updated images since you last run the bot, and do the subqueries to commons with that smaller subset?

Please @Devnull do not reopen the task unnecessarily, we still see it and can comment on it even if it is closed.

@zeljkofilipin very cool, how does it work with vscode features like autocomplete and hover hints on code, and things like that? Or search and replace?

Hey @Aniket, you may want to have a look at these two links:

Hi @jwang, I read through and did some format and copy edits, hopefully small tweaks. Let me know if something is inappropriate and I can revert it. Very nice research 👍👏

I was talking with Andre the other day about this and he pointed me to this task.

Sounds good! I'll ping you once I start looking into it 👍

I just got all the reminders and some other “Unsubscribe” emails all at once.

We should verify somehow that:

• It isn't just me
• If other kinds of email delivery are working, like the welcome emails

Hey @Gilles , we're submitting this like you asked with an initial overview, but we are still fleshing out a tech spec and we will be discussing it with tech com and the architecture team during March.

Approved from my side

In T244772#5898175, @Krinkle wrote:

@Jhernandez If you've determined that there is no chance for data leak or data corruption as result of this silent error, and determined there is no user-visible impact or that it doesn't matter right now from a product perspective, then I would recommend patching the code to simply tolerate this error as-is.

Hey @JoeWalsh, are we set for offline stuff with mobile-html? Can we close this task?

Moved to tracking as we are can't directly work on this, but we can schedule office hours and code review any work the android team does on this like last quarter.

Given there is no impact I'm making this Low and backlog.

We should check if this is the case on /page/mobile-html as well.

In T241180#5828095, @egardner wrote:

We will definitely need to study any possible performance impacts from using the template compiler at runtime. If it turns out that relying on the compiler at runtime causes significant perf regressions then we will need to come up with another solution (and re-open some points in this discussion).

Looking forward to this research.

But I'm actually optimistic about this. MediaWiki's ResourceLoader already supports client-side template compilation using Mustache Templates. This works fine and is used in a number of places in production now. The functionality we're talking about here is very similar. Browsers are very good at parsing strings into DOM nodes quickly and efficiently.

In T241180#5827364, @egardner wrote:

There will be some limitations to this approach:

1. we'll rely on Vue's built-in template compiler for the time being, which means shipping a little bit of additional code in production;

Strange, before for me Carnivorous redirected with a 302 to Carnivore and now it is a 200 with type no-extract.

It seems like RESTBase is not resolving the redirects when the request is CORS.

I'm glad a recommendation has been made, and that we can move things forward in other very important topics that maybe are more foundational than the framework, like build tools and processes, and developer workflows. Those decisions will directly affect how any library is used.

We need to discuss with Product and Design if we want to get rid of the whole thing, or leave a UI element to open the whole list of references that were removed, or not if those are available somewhere else.

This may be related to making the request from a different domain with CORS, and the preflight requests and the behavior when a redirect is returned

We discussed it and it seems very hard with the user generated content to put in special behavior with these two because of how some templates behave or how the HTML is produced.

Can Design please sign off that this change is ok for both platforms in terms of color before we get to it?

hey @MSantos, is this a subtask of T238830: Profile proton memory usage for Helm chart?

@Pchelolo Apparently internal services are using https, should we update the node services template to do so in production? Thoughts?

We should also update the markdown tutorial/docs on page library pagelib/docs/pcs/pcs.md.

Let's use the JSDoc format and the tooling/theme for publishing can happen separately.

Hey @MSantos can you fill the task description with more detail? Maybe using the template?

From grooming discussion: Eventually this component should be updated to use structured data on commons captions whenever there is enough data.