Thanks @Ladsgroup, understood on the extra complexity.

This has probably been discussed at length, but I've wondered a little if it would be possible to have same-host pathing (or at least shared second level domain, when not already a .wikimedia.org domain - still independent of the main HTML serving...although the task Description suggests a shared text cluster anyway) for the thumbnail URLs so that cookies and other things come in the request when embedded in a page for a normal web browser.

Done. Thanks all.

Updates posted

Sorry, missed your message @Ottomata .

Patches up for review. @mforns and I had spot checked the other day, and @JAllemandou and I had a read today as well. More review appreciated, though.

In T420695#11949520, @mpopov wrote:

• https://wikitech.wikimedia.org/w/index.php?title=Data_Platform%2FSystems%2FGrowthbook&diff=2418580&oldid=2404853 (diff also includes Balthazar's operational instructions, can't claim credit for those)
• https://wikitech.wikimedia.org/w/index.php?title=Data_Platform%2FData_access&diff=2418592&oldid=2387620
• https://wikitech.wikimedia.org/w/index.php?title=SRE%2FLDAP%2FGroups&diff=2418593&oldid=2413528

@JMonton-WMF I'm sorry, I missed your question!

Oooh...maybe page_title_unnamespaced or page_title_denamespaced would get it accurately (even if it isn't technically de-namespacing, let's say), but avoid any other ambiguity. I don't have particular serious problem with page_title_unprefixed...just the mild reservation about the term 'prefix' being prone to be conflated with that Special:PrefixIndex meaning, its dropdown lets one choose the namespace. (Perhaps comically one might note that if one leaves the namespace at Article on that special page and types in a known namespace string, well, because the main namespace implicitly lacks a namespace string there, one can get things like, for example: https://en.wikipedia.org/wiki/Talk:A%26M ; but that does not impugn the form's intent of focusing upon a particular namespace; it just has that side effect.). Your call @Ottomata! This is proof yet again naming things is hard.

Hmm, page_title_no_ns...?

In T426268#11942415, @Ottomata wrote:

changing the present emission behavior on page_title constitutes a breaking change.

Indeed. Okay new field.

In terms of guarantees on the data, changing the present emission behavior on page_title constitutes a breaking change.

In T426347#11923079, @Ottomata wrote:

What you want is a mediawiki_html_content_current like Mediawiki_content_current_v1

(Post message send thought: namespace_name could also simply be the canonical one, and then we could let namespace_name_local be the one that is distinctive for the given wiki; that way we get both conformance to other schemata, but the desirable property to have the bona fide prefix for the given wiki.)

namespace_name is usually the English canonical version. Maybe do both of these?

Bumping reminder to self to next week.

@pmiazga confirmed, I think.

@Miriam happy to do a working meeting next week if you can find a mutually available time in case of any questions. I believe @JMoore-WMF may also be coordinating another working meeting, so if you and Justin can combine efforts here with @Maryana so we can put our minds together synchronously I think that's best (I have limited availability, but am happy to do 45-60 minutes next week across a session or two). Also happy to interface one-to-one on Meet (just schedule the time) if a coordinated mutually available time isn't possible for everyone.

I've set reminders for May 13 & 14, 2026 for myself to update the documentation on wiki, my thought being the systems are likely to be in place by around then (and if not, can push it back a little). I realized it's better to just write this once rather than write and rewrite it. @JVanderhoop-WMF and @KReid-WMF are marked as Optional on my calender reminders for visibility (and in hopes of prompts if needed just in case).

In T419021#11779737, @mpopov wrote:

Moved initial lists of users to spreadsheet for easier management and review

In T419622#11732154, @taavi wrote:

Drive-by comment: as email values in LDAP are inherintly not trustworthy, and as you're already checking membership in trusted groups LDAP and Unix that already grant access to private user information, to me your focus on user email domains here is a bunch of unnecessary complexity for no extra gain.

Confirmed out of band with @JVanderhoop-WMF (meeting) and @brouberol (IM on team chat) we look okay to go here. I've filed a number of subtasks in the task graph of T417912: FY25-26 SDS2.2.7 / SDS 2.3.3 Application Permissions, and have updated an annual calendar reminder about triggering an annual access review (that will be in addition to any automation). I'm out for a bit, and have asked for Julie and Katherine to manage progress.