Page MenuHomePhabricator

Mooeypoo (Moriel Schottlender)
Principal Systems Architect, Architecture Team

Projects (21)

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Monday

  • Clear sailing ahead.

User Details

User Since
Nov 18 2014, 11:57 PM (349 w, 3 d)
Availability
Available
IRC Nick
mooeypoo
LDAP User
Mooeypoo
MediaWiki User
Mooeypoo [ Global Accounts ]

Recent Activity

Wed, Jul 7

Mooeypoo added a comment to T284783: NavPopups should not use ♂♀ icons to describe how one wants to be addressed.

I still don’t think hiding this piece of information is a solution. If there’s really a demand for four options (she/her, he/him, they/them, prefer not to say or don’t care), then the most appropriate solution is give people four options. (Four options in the preferences and API result, but still just three {{GENDER:}} forms.) Even though deliberately choosing they/them is somewhat Anglocentric, as other languages may not have one established third form—for example, in German there are several attempts, none of them as widespread as the English they/them. Letting Germans have exactly one non-binary pronoun is just as annoying as not being able to differentiate between deliberately choosing they/them in English and not choosing anything.

Wed, Jul 7, 6:11 PM · Navigation-Popups-Gadget

Jun 30 2021

Mooeypoo added a comment to T284258: Knowledge store data model.

Yes to all of the above -- we definitely want to make sure we're iterating on a data model, and it's definitely important to decide on the standard. We do have a couple of artifacts touching on this and we'd love to share those.

Jun 30 2021, 6:06 PM · tech-decision-forum
Mooeypoo added a comment to T285880: Evaluate pros & cons of CSS utility classes.

We should make sure we choose a library that properly supports RTL. It seems Tailwind has support, but potentially a bit over complicated, see: https://github.com/tailwindlabs/tailwindcss/discussions/1492#discussioncomment-6061

Jun 30 2021, 4:02 PM · Design-Systems-team-board (Kanban Board 2021-2022), CSS, WVUI

Jun 14 2021

Mooeypoo added a comment to T284783: NavPopups should not use ♂♀ icons to describe how one wants to be addressed.

(I'm one of the maintainers, although that status is highly unofficial.) I'll just go with what Tacsipacsi said; "he/him", "she/her", or nothing. Done in https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js&direction=prev&oldid=1028542485.

Jun 14 2021, 5:23 PM · Navigation-Popups-Gadget
Mooeypoo added a comment to T279483: When I reply to someone, please indicate the person's gender.

To be honest, my main pet peeve is that mediawiki is taking a choice that the user usually thinks is private (preferences), that is then used to show things differently only for them in their context - and then turning around and using it publicly.

Jun 14 2021, 4:36 PM · Editing-team (FY2021-22 Kanban Board), Gender-Support, DiscussionTools
Mooeypoo added a comment to T284783: NavPopups should not use ♂♀ icons to describe how one wants to be addressed.

Gender, sex, and language pronouns are three distinct notions. The article discusses some application of this, but the first sentence can't be clearer:

A gender symbol is a pictogram or glyph used to represent biological sex and gender in biology or medicine"

Jun 14 2021, 2:36 AM · Navigation-Popups-Gadget

Jun 13 2021

Mooeypoo added a comment to T284783: NavPopups should not use ♂♀ icons to describe how one wants to be addressed.
In T284783#7153630, @mb wrote:

So, the problem is that the icons -- "female" and "male" symbols -- represent sex, in a binary way, they do not represent pronouns or language choice.

That's your opinion. I submit that those icons in Wikipedia do represent exactly what choice the user made in "Preferences": "How do you prefer to be described?" – "they/their", :she/her", "he/his".

Jun 13 2021, 7:21 AM · Navigation-Popups-Gadget
Mooeypoo added a comment to T284783: NavPopups should not use ♂♀ icons to describe how one wants to be addressed.
In T284783#7153596, @mb wrote:

[…] because someone's gender does not equal how they want to be referred to […]

The choice of how people want to be referred to in messages is limited to three: 1) neutral ("they/their" – the default); 2) feminine ("she/her"); 3) masculine ("he/his"). The person's actual sex or current gender is of no concern. Based on the user's choice, or the default, Popups displays nothing or a symbol. What other options should there be in "Preferences"? (which is off-topic here)

Jun 13 2021, 1:40 AM · Navigation-Popups-Gadget

Jun 11 2021

Mooeypoo added a comment to T284783: NavPopups should not use ♂♀ icons to describe how one wants to be addressed.
In T284783#7151156, @mb wrote:

You lost me. Users chose the term (language) how they want to be addressed. Popups reflects that choice by displaying a symbol, a sign. If users chose neither female nor male, no sign is displayed. Are you unhappy with the sign? Which one do you prefer? What purpose would be advanced by displaying no sign?

Jun 11 2021, 4:21 PM · Navigation-Popups-Gadget
Mooeypoo added a comment to T284783: NavPopups should not use ♂♀ icons to describe how one wants to be addressed.
In T284783#7150655, @mb wrote:

If people chose a gender term in their preferences, that should be observed. Showing a symbol in popups is the most concise way of doing that.

Jun 11 2021, 5:10 AM · Navigation-Popups-Gadget
Mooeypoo added a comment to T284783: NavPopups should not use ♂♀ icons to describe how one wants to be addressed.
Jun 11 2021, 1:56 AM · Navigation-Popups-Gadget

Jun 10 2021

Mooeypoo awarded T284783: NavPopups should not use ♂♀ icons to describe how one wants to be addressed a Love token.
Jun 10 2021, 11:20 PM · Navigation-Popups-Gadget

Jun 9 2021

Mooeypoo added a comment to T279483: When I reply to someone, please indicate the person's gender.

This is a fascinating discussion and I actually am not entirely sure I have a good answer to this. As a woman who speaks gendered language, this touches all my pet peeves at once, which would have been helpful to formulate an opinion, except some of those pet peeves are from one side and the others on the other.

Jun 9 2021, 11:03 PM · Editing-team (FY2021-22 Kanban Board), Gender-Support, DiscussionTools

May 26 2021

Mooeypoo placed T213476: Create a SimpleDialogWidget class to enable creating simple dialogs easily up for grabs.
May 26 2021, 8:01 PM · Patch-Needs-Improvement, OOUI
Mooeypoo added a comment to T282835: Evaluate use of TypeScript in WVUI.

Correct. My "concern" is simply about the added abstraction of a compiler in javascript.

May 26 2021, 12:43 PM · Design-Systems-team-board, WVUI
Mooeypoo added a comment to T282835: Evaluate use of TypeScript in WVUI.
  1. I agree with @Mooeypoo’s "Using TypeScript does mean increasing the abstraction of code. That is, it means relying on the TypeScript compiler, for better and worse." However, viewed in context of popular other extensions of JavaScript, TypeScript is quite tame; Codebases using JSX and several very future babel extensions are easily as hard or harder to read and are based on a more complex setup. And due to the long time without a native module system, ES6 imports are still not normal in JavaScript – most code de-facto relies on some compilation for them even if one just develops locally (And I don't like it).
May 26 2021, 7:39 AM · Design-Systems-team-board, WVUI

May 14 2021

Mooeypoo added a comment to T282835: Evaluate use of TypeScript in WVUI.

From my personal perspective, and my experience with OOUI that was meant to be a shared library used by teams to create components, I am extremely intrigued by the potential benefits that TypeScript can offer with the IDE hints and developer-help that you've mentioned above. I think it might be worth exploring whether it's worth using TypeScript if not in the entire wvui library, then even only on the "lower/common" underlying code that others will rely on -- llike mixins and base components.

May 14 2021, 2:55 PM · Design-Systems-team-board, WVUI

Jan 7 2021

Mooeypoo added a comment to T271054: If loading a preset search in the URL, the page is non dynamic.

I am not sure if you've done anything in the past couple of days, but I haven't encountered this issue anymore.

Jan 7 2021, 12:46 AM · Structured-Data-Backlog (Current Work), SDAW-MediaSearch (MediaSearch-ReleaseCandidate2)

Jan 3 2021

Mooeypoo updated the task description for T271054: If loading a preset search in the URL, the page is non dynamic.
Jan 3 2021, 2:04 AM · Structured-Data-Backlog (Current Work), SDAW-MediaSearch (MediaSearch-ReleaseCandidate2)
Mooeypoo created T271054: If loading a preset search in the URL, the page is non dynamic.
Jan 3 2021, 2:03 AM · Structured-Data-Backlog (Current Work), SDAW-MediaSearch (MediaSearch-ReleaseCandidate2)

Dec 7 2020

Mooeypoo added a comment to T265078: [M] Improve multilingual support for QuickView metadata.

Re your notes, in reverse order:

Dec 7 2020, 10:47 PM · MW-1.36-notes (1.36.0-wmf.25; 2021-01-05), SDAW-MediaSearch (MediaSearch-ReleaseCandidate2), Structured-Data-Backlog (Current Work), Structured Data Engineering

Oct 28 2020

Mooeypoo placed T187959: Create error message to alert users that they have gone beyond 99 markers created up for grabs.
Oct 28 2020, 2:41 AM · Growth-Team-Filtering, User-TheDJ, Growth-Team, Collaboration-Feature-Rollouts (Collaboration-Maps), Maps (Kartographer)
Mooeypoo placed T203564: [BUG] Windows Edge 17 and IE11 do not display info icons up for grabs.
Oct 28 2020, 2:40 AM · Browser-Support-Internet-Explorer, Browser-Support-Microsoft-Edge, MediaWiki-extensions-TemplateWizard, Community-Tech
Mooeypoo placed T197011: Full-width maps cannot be properly edited in VisualEditor up for grabs.
Oct 28 2020, 2:40 AM · Maps (Kartographer), Collaboration-Feature-Rollouts (Collaboration-Maps)
Mooeypoo placed T189144: RTL support for Interaction Timeline up for grabs.
Oct 28 2020, 2:32 AM · I18n, RTL, InteractionTimeline

Oct 25 2020

Mooeypoo added a comment to T265078: [M] Improve multilingual support for QuickView metadata.

Chrome and FF seem to be somewhat smart about the date and are rendering it properly in RTL

Oct 25 2020, 7:48 AM · MW-1.36-notes (1.36.0-wmf.25; 2021-01-05), SDAW-MediaSearch (MediaSearch-ReleaseCandidate2), Structured-Data-Backlog (Current Work), Structured Data Engineering
Mooeypoo created T266399: Banners that aren't translated look mangled on RTL wiki on mobile .
Oct 25 2020, 7:25 AM · Wiki-Loves-Monuments, MediaWiki-extensions-CentralNotice

Oct 11 2020

Mooeypoo updated Mooeypoo.
Oct 11 2020, 8:55 PM

Oct 9 2020

Mooeypoo added a comment to T265080: Force LTR for filenames.

PS: If the idea is not general, but only for Commons and only when the user interface language is an LTR language (such as English) then maybe this is worth exploring further. But for RTL wikis (or even for LTR wikis, when the user selects an RTL interface language in their preferences) this can mess things up.

Oct 9 2020, 6:53 PM · RTL, I18n, SDAW-MediaSearch (MediaSearch-ReleaseCandidate2), Structured-Data-Backlog (Current Work), Structured Data Engineering
Mooeypoo added a comment to T265080: Force LTR for filenames.

With all due respect, I strongly oppose.

For better or worse, we have many files whose name (not extension, but name) is in an RTL language. Take, for instance, پرونده:ایوری در کنار سفره هفت سین.jpg (where "پرونده" is the localization of the "File" namespace), which is one of tens of thousands of such files (perhaps even more). With our current setup, the filename is show correctly:

Screen Shot 2020-10-08 at 7.34.14 PM.png (110×1 px, 22 KB)

But if we force an LTR display, this is what we get, where the "پرونده" prefix is incorrectly displayed right next to the file extension (".jpg")

Screen Shot 2020-10-08 at 7.33.58 PM.png (98×1 px, 22 KB)

You might say: well let's keep it RTL for files with an RTL name, but force it to be LTR for all other cases. But that introduces inconsistency while not gaining anything.

PS: If the idea is not general, but only for Commons and only when the user interface language is an LTR language (such as English) then maybe this is worth exploring further. But for RTL wikis (or even for LTR wikis, when the user selects an RTL interface language in their preferences) this can mess things up.

Oct 9 2020, 6:35 PM · RTL, I18n, SDAW-MediaSearch (MediaSearch-ReleaseCandidate2), Structured-Data-Backlog (Current Work), Structured Data Engineering

Oct 1 2020

Mooeypoo added a comment to T258935: Add a limit to the number of sites a user can watch.

Hi, Moriel, what's up. Here are my 5 cents. I really don't think that the first option should be implemented. I do not use the global watchlist for my prime wiki. This is because I prefer the regular watchlist there, that has much more functionality (remember WLM (-: ?). I do use the global watchlist on the rest, dozens of times every day, instead of opening all the wikis that I do not reach oftenly.
Also, I use the Global Watchlist for 19 wikis, and I do not think there should be only 5. It works very fast anyway. Moreover, I do not think the new extension will be helpful for me, if it will not show at least 6 wikis - meta, mediawiki, commons, wikidata, enwiki and ruwiki.

Oct 1 2020, 7:51 PM · MW-1.36-notes (1.36.0-wmf.20; 2020-12-01), MediaWiki-extensions-GlobalWatchlist, User-DannyS712

Sep 30 2020

Mooeypoo added a comment to T264239: Wikisource: Rename the WSExport tool.

Honestly beyond the awkward connotation (!) in that name, I'd offer that the name of the product should be more descriptive of what the product actually does. This product is available especially to people who are not familiar with wiki-speak, who come in and want to export pieces of text, books, etc, to standalone formats. Changing the name to reflect the use and purpose of the tool can be beneficial on top of the fact that we should really avoid sticking to very awkward connotation from the abbreviation.

Sep 30 2020, 9:04 PM · Community-Tech (Kanban-2020-21-Q2), WS Export, All-and-every-Wikisource
Mooeypoo added a comment to T258935: Add a limit to the number of sites a user can watch.

Okay, so the limit was being applied to the number of sites that were queried, and the extension is only deployed on meta. Makes sense.
The current code, the user script, and my assumption were all for users choosing the sites themselves.
Currently, the requests are all made in parallel - should they be made in series instead?

Sep 30 2020, 6:47 PM · MW-1.36-notes (1.36.0-wmf.20; 2020-12-01), MediaWiki-extensions-GlobalWatchlist, User-DannyS712
Mooeypoo added a comment to T258935: Add a limit to the number of sites a user can watch.

The idea here is that since the global watchlist contacts the individual Wikipedias' APIs, we want to limit how many concurrent requests are sent, because sending a request to 900+ apis is unreasonable.

Sep 30 2020, 6:37 PM · MW-1.36-notes (1.36.0-wmf.20; 2020-12-01), MediaWiki-extensions-GlobalWatchlist, User-DannyS712

Sep 28 2020

Mooeypoo added a comment to T264022: Story idea for Blog: Modernization in the dynamic world of the internet.

Note: I sent the draft document link directly to @srodlund

Sep 28 2020, 11:34 PM · Technical-blog-posts
Mooeypoo created T264022: Story idea for Blog: Modernization in the dynamic world of the internet.
Sep 28 2020, 5:04 PM · Technical-blog-posts

Sep 10 2020

Mooeypoo added a comment to T261029: Decide on UI framework(s) to start the project with.

I'm jumping in (by request! ;) to give my recommendation: I would 100% go with VueJS on this, even only for the reason that recently this was the framework adopted by the foundation for our frontend modernization.

Sep 10 2020, 2:28 AM · Toolhub

Jul 21 2020

Mooeypoo added a comment to T258457: WWT makes API request on every page view before button is clicked..

Also, this shouldn't act as a gadget; we did not officially release it as such and it is not optimized to be that. We're supporting it as a browser extension, and we're (ab)using the ResourceLoader queue "feature" to insert ourselves as if we're a gadget,but still working from the browser.

Jul 21 2020, 12:50 AM · Community-Tech, Who-Wrote-That
Mooeypoo added a comment to T258457: WWT makes API request on every page view before button is clicked..

IIRC, we need to ask for the translated message for the button/link, and while we're at it we're asking for the rest of the messages. I don't think we can get away with not calling it at all and still have the link appear? (though admittedly I need to delve into the code again to see if it's a timing issue)

Jul 21 2020, 12:48 AM · Community-Tech, Who-Wrote-That

Jul 8 2020

Mooeypoo created T257502: Requesting access to analytics-privatedata-users for mooeypoo.
Jul 8 2020, 6:52 PM · SRE, SRE-Access-Requests

Jul 7 2020

Mooeypoo removed a watcher for Community-Tech: Mooeypoo.
Jul 7 2020, 2:39 AM

Jun 30 2020

Mooeypoo added a comment to T255504: Decouple Special:Investigate toollinks from Special:CheckUser toollinks.

@Mooeypoo brings up an important point of separating the concerns (separating the config from the translations). However, it seems like it might be a slight abuse of the translation system to use it for config, even though, as @Tchanders point out, it's already being used that way. I wasn't able to find any other messages being used in a JSON format (they all seem to use a custom format).

Jun 30 2020, 2:13 AM · MW-1.35-notes (1.35.0-wmf.40; 2020-07-07), Anti-Harassment (The Letter Song), Patch-For-Review, CheckUser
Mooeypoo updated subscribers of T252812: Investigate watchlist sizes (limiting or handling large ones properly).

@Marostegui (feel free to tag anyone else that may need to participate here?), we've discussed this extensively in the team after running into some challenges, and ran some analysis on the usage of the watchlist table. We want to see if we can reframe the problem and make sure we can find a viable way forward.

Jun 30 2020, 12:31 AM · Platform Team Workboards (Clinic Duty Team), Community-Tech (Kanban-2020-21-Q1), Expiring-Watchlist-Items

Jun 29 2020

Mooeypoo added a comment to T255504: Decouple Special:Investigate toollinks from Special:CheckUser toollinks.

Another idea, followup from conversations in the team:

Jun 29 2020, 8:21 PM · MW-1.35-notes (1.35.0-wmf.40; 2020-07-07), Anti-Harassment (The Letter Song), Patch-For-Review, CheckUser

May 29 2020

Mooeypoo added a comment to T194529: Allow a user to be blocked from moving/renaming pages.

There's an issue here we should account for, or at least be aware of, that may make this block action less impactful than we'd think. If we go with @DannyS712 idea, we could probably block the actual action of moving a page (when you hit the menu action item for "move") but there are other ways to move pages manually.

May 29 2020, 9:15 PM · MW-1.37-notes (1.37.0-wmf.4; 2021-05-04), Anti-Harassment (The Letter Song), MediaWiki-Blocks, User-DannyS712, MediaWiki-Page-rename

May 22 2020

Mooeypoo added a comment to T249259: Watchlist Expiry: Update popup loading behavior when watching via star [medium].

The module to bundle this is with would be that same module (the watch JS module). See packageFiles.

May 22 2020, 5:55 PM · Community-Tech (Kanban-2020-21-Q1), MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), Expiring-Watchlist-Items, archived--TCB-Team

May 21 2020

Mooeypoo added a comment to T250212: Watchlist Expiry: Add UI behavior in Special:Watchlist [medium].

It looks like the output should be added to the table entry for the page rather than just the rows outputted for a single change, in "EnhancedRecentChanges". Good catch, @Scardenasmolinar

May 21 2020, 7:10 PM · MW-1.35-notes (1.35.0-wmf.39; 2020-06-30), Community-Tech (Kanban-2019-20-Q4), Expiring-Watchlist-Items, archived--TCB-Team

May 20 2020

Mooeypoo added a comment to T249259: Watchlist Expiry: Update popup loading behavior when watching via star [medium].

On StructuredDiscussion talk pages, I am seeing inconsistent popup behaviour when clicking the watch star.

Watching talk page

  1. Visit a talk page which is unwatched and has StructuredDiscussions enabled (go to Special:Preferences#mw-prefsection-betafeatures, check "Structured Discussions on user talk" and Save).
  2. Click the watch star. You will see the usual watch message:
    first_watch_cropped.png (213×551 px, 17 KB)
  3. Click the watch star again. You will see the usual unwatch message:
    first_unwatch_cropped.png (189×544 px, 17 KB)
  4. Click the watch star again. You will see the special StructuredDiscussion message:
    second_watch_cropped.png (216×550 px, 21 KB)

With watchlist expiry disabled, you see the special StructuredDiscussion message when you first click watch (step 2).

Unwatching talk page

  1. Visit a talk page which is watched and has SD enabled.
  2. Click the watch star. You will see the SD message telling you you have subscribed to the page (even though you have not):
    second_watch_cropped.png (216×550 px, 21 KB)

I can reproduce both of the above on beta, which has watchlist expiry enabled ($wgWatchlistExpiry = true).

I have not been able to reproduce either of the above with watchlist expiry disabled (on my local version).

@Scardenasmolinar I know @Mooeypoo worked on StructuredDiscussion, so she might know more about this.

May 20 2020, 12:33 AM · Community-Tech (Kanban-2020-21-Q1), MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), Expiring-Watchlist-Items, archived--TCB-Team

May 19 2020

Mooeypoo added a comment to T249259: Watchlist Expiry: Update popup loading behavior when watching via star [medium].
From Gerrit:

This should not be output in the <head> of every production page view.

The information is static and identical side-wide. Bundle it with the module that neeeds it instead. This avoids delaying article rendering.

May 19 2020, 11:15 PM · Community-Tech (Kanban-2020-21-Q1), MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), Expiring-Watchlist-Items, archived--TCB-Team

May 15 2020

Mooeypoo added a comment to T252860: WWT fails on `James Alexander Chiles`.

We definitely rely on user rights when we show (and not show) the information when a revision is suppressed or deleted, by feature (not bug) so it sounds reasonable that if the revision was deleted, you'd get a popup with hidden details.

May 15 2020, 9:33 PM · User-DannyS712, Who-Wrote-That, Community-Tech
Mooeypoo added a comment to T252860: WWT fails on `James Alexander Chiles`.

Can you check if this happened at a specific revision? I just tried it now, and I see the entire text highlighted, given credit to your username as have written 100% of the page.

May 15 2020, 9:32 AM · User-DannyS712, Who-Wrote-That, Community-Tech

May 14 2020

Mooeypoo created T252812: Investigate watchlist sizes (limiting or handling large ones properly).
May 14 2020, 7:18 PM · Platform Team Workboards (Clinic Duty Team), Community-Tech (Kanban-2020-21-Q1), Expiring-Watchlist-Items

May 8 2020

Mooeypoo added a comment to T217363: Consider minimizing the presence of Partial Blocks UI elements on Special:Block.

Today I learned ;) https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/htmlform/HTMLForm.php$95

May 8 2020, 12:30 AM · User-notice, MediaWiki-Blocks, Patch-For-Review, User-DannyS712, MediaWiki-Interface, WMF-Design, Design, Anti-Harassment

May 7 2020

Mooeypoo added a comment to T217363: Consider minimizing the presence of Partial Blocks UI elements on Special:Block.

Using HTML form's hide-if should take care of accessibility concerns

@Mooeypoo @Volker_E I don't know much about hide-if. Is it implemented in an accessible way?

May 7 2020, 11:58 PM · User-notice, MediaWiki-Blocks, Patch-For-Review, User-DannyS712, MediaWiki-Interface, WMF-Design, Design, Anti-Harassment

May 5 2020

Mooeypoo added a comment to T251894: Requesting WMF-NDA group membership for AHT engineers.

Tagging @aezell in case manager approval is needed.

@Mooeypoo do you need access too?

May 5 2020, 4:49 PM · WMF-NDA-Requests

May 1 2020

Mooeypoo updated subscribers of T251590: Inline FieldLayout isn't inline when it contains a TextInputWidget.

Hmmmm, we really don't want inline labels at most. They are bad, bad, bad. User research (I'd need to google it for you) has shown that inline labels and text inputs make it really hard to quickly navigate/skim forms for users. Haven't yet come across the combination of text input and inline.

Sure, but there are exceptions to this rule, and when those exist, we do need a way to do it.

May 1 2020, 10:55 PM · OOUI
Mooeypoo added a comment to T251611: Move the Graph extension's TableWidget upstream to core.

I think that the question of which "upstream" is a good one; ideally, this actually could be generic enough to be in OOUI tiself, but I agree that it probably just increases complexity and size for probably very low usage.

May 1 2020, 9:01 PM · MediaWiki-extensions-Graph, JsonConfig, covid-19, Commons-Datasets
Mooeypoo updated subscribers of T251590: Inline FieldLayout isn't inline when it contains a TextInputWidget.

That's weird; we do have inline forms with text fields, I'd have expected this to be found as a bug before.... :\
If FieldLayout allows for an inline config, then it should respect inline settings.

May 1 2020, 3:16 AM · OOUI

Apr 21 2020

Mooeypoo updated subscribers of T249259: Watchlist Expiry: Update popup loading behavior when watching via star [medium].

After a bit of back and forth with @Catrope and examining the challenges here with an OOUI popup, Roan made a good point about at least testing whether the alternative is viable.

Apr 21 2020, 4:04 AM · Community-Tech (Kanban-2020-21-Q1), MW-1.35-notes (1.35.0-wmf.34; 2020-05-26), Expiring-Watchlist-Items, archived--TCB-Team

Apr 17 2020

Mooeypoo updated subscribers of T249059: Requesting access to analytics-privatedata-users for tchanders, dmaza, dbarratt, wikigit.

Thank you everyone for all the feedback and back and forth, and I apologize for any misunderstandings here.

Apr 17 2020, 12:49 AM · Anti-Harassment, SRE, SRE-Access-Requests

Apr 9 2020

Mooeypoo moved T249782: Watchlist Expiry: ClearUserWatchlistJob doesn't delete from watchlist_expiry from Ready to In Development on the Community-Tech (Kanban-2019-20-Q4) board.
Apr 9 2020, 5:26 PM · MW-1.35-notes (1.35.0-wmf.31; 2020-05-05), Community-Tech (Kanban-2019-20-Q4), archived--TCB-Team, Expiring-Watchlist-Items
Mooeypoo edited projects for T249782: Watchlist Expiry: ClearUserWatchlistJob doesn't delete from watchlist_expiry, added: Community-Tech (Kanban-2019-20-Q4); removed Community-Tech.
Apr 9 2020, 5:26 PM · MW-1.35-notes (1.35.0-wmf.31; 2020-05-05), Community-Tech (Kanban-2019-20-Q4), archived--TCB-Team, Expiring-Watchlist-Items

Apr 7 2020

Mooeypoo added a comment to T249059: Requesting access to analytics-privatedata-users for tchanders, dmaza, dbarratt, wikigit.

@Nuria I'm a little confused, and I'd like to clarify something.

Apr 7 2020, 5:33 PM · Anti-Harassment, SRE, SRE-Access-Requests

Mar 31 2020

Mooeypoo added a comment to T248496: Watchlist Expiry: Add a popup to watch pages temporarily - BEING WORKED ON IN SEPARATE SUBTASKS.

Split to two tickets:

Mar 31 2020, 11:33 PM · Expiring-Watchlist-Items, archived--TCB-Team, Community-Tech
Mooeypoo updated the task description for T248496: Watchlist Expiry: Add a popup to watch pages temporarily - BEING WORKED ON IN SEPARATE SUBTASKS.
Mar 31 2020, 9:53 PM · Expiring-Watchlist-Items, archived--TCB-Team, Community-Tech
Mooeypoo updated the task description for T248496: Watchlist Expiry: Add a popup to watch pages temporarily - BEING WORKED ON IN SEPARATE SUBTASKS.
Mar 31 2020, 9:53 PM · Expiring-Watchlist-Items, archived--TCB-Team, Community-Tech
Mooeypoo created T249059: Requesting access to analytics-privatedata-users for tchanders, dmaza, dbarratt, wikigit.
Mar 31 2020, 9:13 PM · Anti-Harassment, SRE, SRE-Access-Requests
Mooeypoo added a comment to T246797: Structured Data on Commons: RTL support for geographical co-ordinates.

(egh, my screenshot didn't work, but--) w00t, it works now!

Mar 31 2020, 7:12 PM · MW-1.35-notes (1.35.0-wmf.26; 2020-03-31), Structured-Data-Backlog (Current Work), RTL, Structured Data Engineering, I18n
Mooeypoo added a comment to T246797: Structured Data on Commons: RTL support for geographical co-ordinates.

Sweet, I think this should fix it. I +2'ed, so it should be available on beta soon to test.

Mar 31 2020, 5:22 AM · MW-1.35-notes (1.35.0-wmf.26; 2020-03-31), Structured-Data-Backlog (Current Work), RTL, Structured Data Engineering, I18n

Mar 27 2020

Mooeypoo added a comment to T246797: Structured Data on Commons: RTL support for geographical co-ordinates.

Following up since @Etonkovidova has asked me to look into why it's not working:

Mar 27 2020, 12:40 AM · MW-1.35-notes (1.35.0-wmf.26; 2020-03-31), Structured-Data-Backlog (Current Work), RTL, Structured Data Engineering, I18n

Mar 24 2020

Mooeypoo added a watcher for Vue.js: Mooeypoo.
Mar 24 2020, 8:05 PM

Mar 22 2020

Mooeypoo added a comment to T247639: CU 2.0: Create queries required for the Timeline tab [medium].

I would avoid doing things that have no (or huge) limit. Honestly, I think it's a product problem more than a performance one, but since we are checking more than one target (unlike the original) I'd be slightly more careful, and go with pagination.

Mar 22 2020, 4:17 AM · MW-1.35-notes (1.35.0-wmf.26; 2020-03-31), Anti-Harassment (The Letter Song), CheckUser

Mar 13 2020

Mooeypoo updated the task description for T247639: CU 2.0: Create queries required for the Timeline tab [medium].
Mar 13 2020, 9:41 PM · MW-1.35-notes (1.35.0-wmf.26; 2020-03-31), Anti-Harassment (The Letter Song), CheckUser
Mooeypoo created T247641: CU 2.0: Add variant display to the Timeline result list .
Mar 13 2020, 9:40 PM · Patch-For-Review, Anti-Harassment (The Letter Song), CheckUser
Mooeypoo created T247640: CU 2.0: Add the timeline tab with a list of generic structured results [medium].
Mar 13 2020, 9:37 PM · MW-1.35-notes (1.35.0-wmf.32; 2020-05-12), Anti-Harassment (The Letter Song), CheckUser
Mooeypoo created T247639: CU 2.0: Create queries required for the Timeline tab [medium].
Mar 13 2020, 9:34 PM · MW-1.35-notes (1.35.0-wmf.26; 2020-03-31), Anti-Harassment (The Letter Song), CheckUser

Mar 12 2020

Mooeypoo added a comment to T237595: CU 2.0: Timeline tab.

This looks great. Let's just make sure we don't literally copy over what RecentChanges is doing, because the way it is constructing its lines is pretty horrific, and uses monospace-font single-spaces to align tags per each line, etc.

Mar 12 2020, 9:44 PM · Anti-Harassment, CheckUser

Mar 7 2020

Mooeypoo added a comment to T246958: HTMLUsersMultiselectField fails validation when exists is true, but required is false.

@Mooeypoo Thanks yes, that sounds the same as what's described in T246958#5949448. (Prioritize requires over exists; show errors accordingly.)

Oh, I'm sorry if I misrepresented. I got confused with the table showing different messaging exists=true and exists=false... which is different than the suggestion. Sorry, it's really confusing -- I'm just glad we are on the same page!

My main concern was about changing the behaviour of a long-standing and widely-used widget - if that's ok then let's go ahead with this.

Mar 7 2020, 1:51 AM · MW-1.35-notes (1.35.0-wmf.25; 2020-03-24), Anti-Harassment (The Letter Song), MediaWiki-General

Mar 6 2020

Mooeypoo added a comment to T246958: HTMLUsersMultiselectField fails validation when exists is true, but required is false.

Thank you for the thorough analysis, @Tchanders !

Mar 6 2020, 11:02 PM · MW-1.35-notes (1.35.0-wmf.25; 2020-03-24), Anti-Harassment (The Letter Song), MediaWiki-General

Feb 26 2020

Mooeypoo updated the task description for T245078: Watchlist expiry API: Add a expiry parameter when adding an item to the watchlist [medium].
Feb 26 2020, 9:34 PM · MW-1.35-notes (1.35.0-wmf.27; 2020-04-07), Community-Tech (Kanban-2019-20-Q4), Patch-For-Review, Platform Team Workboards (Clinic Duty Team), Expiring-Watchlist-Items, archived--TCB-Team
Mooeypoo added a comment to T245866: Watchlist Expiry: Create 20,000 cap.

Clarification: The cap should be configurable per wiki (per the conversations with DBAs), with a default (for now) of 20,000 items.

Feb 26 2020, 9:23 PM · Expiring-Watchlist-Items, Community-Tech
Mooeypoo updated the task description for T245866: Watchlist Expiry: Create 20,000 cap.
Feb 26 2020, 9:09 PM · Expiring-Watchlist-Items, Community-Tech
Mooeypoo added a comment to T241180: RFC: Adopt a modern JavaScript framework for use with MediaWiki.

Thank you for the excellent detailed reply, @EvanYou. This is a great summary of the points, and gives a good perspective to this RFC and the entire modernization endeavor in general.

Feb 26 2020, 7:03 PM · Front-end-Standards-Group, Vue.js, TechCom-RFC (TechCom-RFC-Closed), Security-Team
Mooeypoo added a comment to T245793: [Firefox 73] Infusing a RadioOptionWidget changes first-child alignment.

Looks good to me. Thank you for figuring it out, @matmarex !

Feb 26 2020, 5:10 AM · OOUI (OOUI-0.37.0), MW-1.35-notes (1.35.0-wmf.22; 2020-03-03), Community-Tech, MediaWiki-extensions-GlobalPreferences, Browser-Support-Firefox, Desktop Improvements
Mooeypoo added a comment to T246053: Give access to Anti Harassment Tools team to production deployment.

Thanks @Dzahn ; I signed the document, and my public ED25519 key is:

Feb 26 2020, 12:13 AM · SRE, SRE-Access-Requests

Feb 25 2020

Mooeypoo added a comment to T245181: Improve test coverage for Special:Investigate.

The general idea of this specific task is to provide the full coverage for the Services, not so much for the special page, which seemed to be more focused and doable. We've added the use cases to guide/inform the approach to the testing.

Feb 25 2020, 10:14 PM · MW-1.35-notes (1.35.0-wmf.23; 2020-03-10), Anti-Harassment (The Letter Song), CheckUser
Mooeypoo created T246053: Give access to Anti Harassment Tools team to production deployment.
Feb 25 2020, 12:48 AM · SRE, SRE-Access-Requests

Feb 21 2020

Mooeypoo added a comment to T245499: Improve performance of Compare query for Special:Investigate.

A couple of small clarifications from the meeting. The third option is the one that's laid out in the description of this ticket, including the product implications.

Feb 21 2020, 11:25 PM · MW-1.35-notes (1.35.0-wmf.25; 2020-03-24), Anti-Harassment (The Letter Song), Performance Issue, CheckUser
Mooeypoo added a comment to T245793: [Firefox 73] Infusing a RadioOptionWidget changes first-child alignment.

Confirmed; on Firefox v73, even on not too large of a screen.

Feb 21 2020, 12:00 AM · OOUI (OOUI-0.37.0), MW-1.35-notes (1.35.0-wmf.22; 2020-03-03), Community-Tech, MediaWiki-extensions-GlobalPreferences, Browser-Support-Firefox, Desktop Improvements

Feb 20 2020

Mooeypoo updated the task description for T245181: Improve test coverage for Special:Investigate.
Feb 20 2020, 7:25 PM · MW-1.35-notes (1.35.0-wmf.23; 2020-03-10), Anti-Harassment (The Letter Song), CheckUser
Mooeypoo added a comment to T244100: Spike: New/Improved OCR tool [8 hours].

We don't have that in production so far, so I'm not sure, especially due to security concerns. We might need to have a gadget where each user must whitelist the toolforge URL individually for security and privacy.

Feb 20 2020, 4:02 PM · Community-Tech (Kanban-2019-20-Q4), Internet-Archive
Mooeypoo moved T245660: PRU: enable pru on test wikidata from Needs Review/Feedback to Product sign-off on the Community-Tech (Kanban-Q3-2019-20) board.

PRU is now available on all test wikis:

Feb 20 2020, 12:25 AM · Community-Tech (Kanban-Q3-2019-20), Password-Reset-Update

Feb 19 2020

Mooeypoo closed T240094: Create required table for new Watchlist Expiry feature as Resolved.

The table has been created. Thank you for all the advice and guidance and help @Marostegui! And thanks, @Anomie, for the input and guidance on the best ways to approach the purging.

Feb 19 2020, 6:19 PM · MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), DBA, Community-Tech (Kanban-Q3-2019-20), Platform Team Workboards (Clinic Duty Team), Expiring-Watchlist-Items
Mooeypoo closed T235005: Spike #2: Watchlist Expiry [12 hours] as Resolved.

Investigation resolved. Next steps on followup tickets. Thank you for everyone's input!

Feb 19 2020, 6:17 PM · Community-Tech (Kanban-Q3-2019-20), archived--TCB-Team, Expiring-Watchlist-Items
Mooeypoo moved T243300: Spike: Investigate Named References in VE [8 hours] from Needs Review/Feedback to Product sign-off on the Community-Tech (Kanban-Q3-2019-20) board.

Investigation is done; we will await next steps to create followup tickets.

Feb 19 2020, 6:14 PM · User-Ryasmeen, Community-Tech (Kanban-2019-20-Q4), Editing-team (Tracking), VisualEditor

Feb 18 2020

Mooeypoo moved T238961: PRU: Improve Security & Standardize Experience for Password Reset [medium] from Needs Review/Feedback to Product sign-off on the Community-Tech (Kanban-Q3-2019-20) board.
Feb 18 2020, 10:33 PM · MW-1.35-notes (1.35.0-wmf.20; 2020-02-18), Community-Tech (Kanban-Q3-2019-20), Password-Reset-Update

Feb 17 2020

Mooeypoo updated subscribers of T245358: Compress table watchlist_expiry.

Will do, @Marostegui ; FYI, I'm also tracking the creation of the table through this ticket: T244631: Create `watchlist_expiry` table in production after wmf.19 is available.

Feb 17 2020, 8:18 AM · DBA

Feb 15 2020

Mooeypoo added a comment to T245082: Add site-wide $wgDefaultWatchlistExpiry configuration variable.

How will the relative bits work with translation and localization if this is truly configurable per wiki?

Feb 15 2020, 7:44 AM · Expiring-Watchlist-Items, archived--TCB-Team, Community-Tech

Feb 14 2020

Mooeypoo added a comment to T238961: PRU: Improve Security & Standardize Experience for Password Reset [medium].

Just to clarify for engineering related thing, am I right to say that, basically, the message ("Both username and email address are required to receive a temporary password via email.") should never appear anywhere, @ifried ?

Feb 14 2020, 10:28 PM · MW-1.35-notes (1.35.0-wmf.20; 2020-02-18), Community-Tech (Kanban-Q3-2019-20), Password-Reset-Update
Mooeypoo updated subscribers of T244579: MediaWiki does not support consistent pagination on non-unique fields.

The product we're discussing (an expansion to CheckUser) deals with potentially large chunks of data from the database, which triggers a number of problems with regard to performance. Regardless of what method we use, we have to come up with a good way to deal with that. After discussing with the team and talking things with @Catrope for some advice around how CheckUser has historically extracted potentially large chunks of information to process, I think we have a slightly changed strategy, and have a plan.

Feb 14 2020, 4:07 AM · MediaWiki-General, TechCom