Page MenuHomePhabricator

Mooeypoo (Moriel Schottlender)
Principal Software Engineer, MediaWiki Engineering Group

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Sunday

  • Clear sailing ahead.

User Details

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

Recent Activity

Wed, Mar 6

Mooeypoo added a comment to T357077: [Spike] Explore different options for code sharing of page-specific configuration between Minerva and Vector.

@Mabualruz the use of a composer library is in scope but doesn't necessarily need to be completed as part of this sprint but it must be discussed.

The important thing here would be to:

  • present the options to the team and the associated trade offs (google doc)
  • Facilitate discussion either async in the document or in person
  • Collect a consensus about how we want to approach this.
  • Document decision in an decision record (ADR) in the patch.
Wed, Mar 6, 6:36 PM · MW-1.42-notes (1.42.0-wmf.22; 2024-03-12), Patch-For-Review, FY2023-24-WE 2.1 Typography and palette customizations, Web-Team-Backlog (FY2023-24 Q3 Sprint 4)

Feb 23 2024

Mooeypoo closed T352205: Analysis: "Unraveling Complexity: Mapping MediaWiki Software Components into User-Driven Workflows" as Resolved.
Feb 23 2024, 12:37 AM · MediaWiki-Engineering, Tech-Docs-Team
Mooeypoo added a comment to T352205: Analysis: "Unraveling Complexity: Mapping MediaWiki Software Components into User-Driven Workflows".

This is published: https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Artifacts/Unraveling_Complexity:_Mapping_MediaWiki_Software_Components_into_User-Driven_Workflows

Feb 23 2024, 12:36 AM · MediaWiki-Engineering, Tech-Docs-Team

Feb 21 2024

Mooeypoo closed T345664: How should client preferences work for logged in users?, a subtask of T91201: [GOAL] Accessibility settings/preferences on desktop and mobile, as Resolved.
Feb 21 2024, 5:59 PM · Web-Team-Backlog (Needs Prioritization (Tech)), Navigation Restructure (Web), Epic, Desktop Improvements (Vector 2022), Wikimania-Hackathon-2016, Wikimania-Hackathon-2015, MediaWiki-Core-Preferences, Design, Accessibility, Wikimedia-Hackathon-2015
Mooeypoo closed T345664: How should client preferences work for logged in users? as Resolved.
Feb 21 2024, 5:59 PM · MW-1.42-notes (1.42.0-wmf.4; 2023-11-07), Patch-For-Review, MediaWiki-Engineering
Mooeypoo added a comment to T345664: How should client preferences work for logged in users?.

Summary from the MW Engineering Group after some discussion about this: As far as the MediaWiki Engineering side of things, this is done.

Feb 21 2024, 5:57 PM · MW-1.42-notes (1.42.0-wmf.4; 2023-11-07), Patch-For-Review, MediaWiki-Engineering

Jan 26 2024

Mooeypoo added a comment to T355880: Decide long term strategy for temp account default.

This is an interesting question. I think that what will help think through this would be listing our the implication and impact of either option.

Jan 26 2024, 5:23 PM · Patch-For-Review, MediaWiki-Engineering, Temporary accounts, Trust and Safety Product Team

Jan 4 2024

Mooeypoo added a comment to T354384: 500 error on Special:EditEventRegistration and Special:EnableEventRegistration on betacluster and local.

This error looked extremely familiar to me, I believe this happens when OOUI isn't setup correctly.

Jan 4 2024, 9:45 PM · MW-1.42-notes (1.42.0-wmf.13; 2024-01-09 ), Campaign-Tools (Campaign-Tools-Current-Sprint), OOUI, CampaignEvents, Campaign-Registration

Jan 3 2024

Mooeypoo closed T322253: Following Auth experiments, a subtask of T297791: Authentication and Authorization Experiment, as Resolved.
Jan 3 2024, 2:26 PM · Authentication-Experiments-2022, SecTeam-Processed, Foundational Technology Requests, Security, Security-Team
Mooeypoo closed T322253: Following Auth experiments as Resolved.

@Mooeypoo: Is there still sense in keeping this ticket open and assigned to you, or can this be closed as resolved/invalid?

Jan 3 2024, 2:26 PM · Authentication-Experiments-2022, WMF-Architecture-Team

Nov 28 2023

Mooeypoo moved T352205: Analysis: "Unraveling Complexity: Mapping MediaWiki Software Components into User-Driven Workflows" from Inbox, needs triage to Cross-team / Strategic on the MediaWiki-Engineering board.
Nov 28 2023, 9:39 PM · MediaWiki-Engineering, Tech-Docs-Team
Mooeypoo claimed T352205: Analysis: "Unraveling Complexity: Mapping MediaWiki Software Components into User-Driven Workflows".
Nov 28 2023, 5:37 PM · MediaWiki-Engineering, Tech-Docs-Team
Mooeypoo created T352205: Analysis: "Unraveling Complexity: Mapping MediaWiki Software Components into User-Driven Workflows".
Nov 28 2023, 5:37 PM · MediaWiki-Engineering, Tech-Docs-Team

Oct 30 2023

Mooeypoo added a comment to T349295: Determine technical approach for Automoderator edit revert component.

This is a really interesting feature!

Oct 30 2023, 4:29 PM · MediaWiki-Platform-Team (Radar), Moderator-Tools-Team (Kanban), Spike, Automoderator

Oct 10 2023

Mooeypoo updated Mooeypoo.
Oct 10 2023, 3:20 PM
Mooeypoo added a member for MediaWiki-Engineering: Mooeypoo.
Oct 10 2023, 3:17 PM

Sep 13 2023

Mooeypoo added a comment to T346100: FloatingUI: Provide proper RTL support.

This looks promising! And.... honestly, anything would have outlier issues in RTL. There will be cases you'll have to run around fixing no matter what you do (OOUI had that too) so you might as well start from something solid that gives you 90% of the functionality. In that aspect, I'd just verify it allows you to tweak / extend properly because you likely will have to with specific edge cases.

Sep 13 2023, 9:02 AM · Patch-For-Review, Design-System-Team (Design-Systems-Sprint-8), Codex

Aug 23 2023

Mooeypoo added a comment to T338817: [M] Limit the number of characters a user can add when reporting.

I don't fully understand what a user will see if we do a byte limit. Otherwise, Kosta's suggestions sound good to me.

Aug 23 2023, 9:31 PM · MW-1.42-notes (1.42.0-wmf.4; 2023-11-07), Trust and Safety Product Sprint (Sprint Bodhrán), Design-System-Team, Incident-Reporting-System

Aug 22 2023

Mooeypoo added a comment to T301618: Move mw:Core_Platform_Team/* pages to mw:Platform_Engineering_Team/*; update Initiative owners.

@larissagaulia: Does "Radar" imply that the Platform Team does not feel responsible to clean up the docs and tickets of the predecessor(s) of the Platform Team?

Aug 22 2023, 2:18 PM · MediaWiki-Engineering, User-AKlapper, Documentation, Platform Engineering

Jun 20 2023

Mooeypoo added a watcher for MediaWiki-Core-Skin-Architecture: Mooeypoo.
Jun 20 2023, 4:39 PM

Jun 15 2023

Mooeypoo added a comment to T339156: Copy-pasting headings from Google Doc to VisualEditor messes up the hierarchy of the headings.

There is a theoretically conceptual way to fix this but I think it's too convoluted to be worth it.

Jun 15 2023, 3:41 PM · VisualEditor-CopyPaste, VisualEditor
Mooeypoo added a comment to T339156: Copy-pasting headings from Google Doc to VisualEditor messes up the hierarchy of the headings.

The downside of this is that if you keep copying and paste back and forth between VE and GDocs, your headings would keep decreasing in level until they were all <h6>.

Jun 15 2023, 3:39 PM · VisualEditor-CopyPaste, VisualEditor
Mooeypoo added a project to T339156: Copy-pasting headings from Google Doc to VisualEditor messes up the hierarchy of the headings: VisualEditor-CopyPaste.
Jun 15 2023, 12:43 AM · VisualEditor-CopyPaste, VisualEditor
Mooeypoo added a project to T339155: Copy-pasting numbered headings from Google Doc to VisualEditor fails: VisualEditor-CopyPaste.
Jun 15 2023, 12:43 AM · MW-1.41-notes (1.41.0-wmf.16; 2023-07-04), Editing-team (Kanban Board), VisualEditor-CopyPaste, VisualEditor

Jun 14 2023

Mooeypoo added a comment to T338404: Deprecate Architecture Team information on wiki.

It all looks good to me (for some definition of good ;) -- the only thing I'd like to discuss and think about is the Artifact page. That page still has relevant documents, and some folks are adding to it. It could still be a good repository of analysis documents regardless of the existence of the team.

Jun 14 2023, 5:20 PM · Tech-Docs-Team, WMF-Architecture-Team
Mooeypoo updated the task description for T339156: Copy-pasting headings from Google Doc to VisualEditor messes up the hierarchy of the headings.
Jun 14 2023, 5:13 PM · VisualEditor-CopyPaste, VisualEditor
Mooeypoo updated the task description for T339155: Copy-pasting numbered headings from Google Doc to VisualEditor fails.
Jun 14 2023, 5:13 PM · MW-1.41-notes (1.41.0-wmf.16; 2023-07-04), Editing-team (Kanban Board), VisualEditor-CopyPaste, VisualEditor
Mooeypoo created T339156: Copy-pasting headings from Google Doc to VisualEditor messes up the hierarchy of the headings.
Jun 14 2023, 5:12 PM · VisualEditor-CopyPaste, VisualEditor
Mooeypoo created T339155: Copy-pasting numbered headings from Google Doc to VisualEditor fails.
Jun 14 2023, 5:12 PM · MW-1.41-notes (1.41.0-wmf.16; 2023-07-04), Editing-team (Kanban Board), VisualEditor-CopyPaste, VisualEditor

Jun 7 2023

hgzh awarded T202916: Stop changing my "Group results by page" prefs based on a URL that I've clicked on a Love token.
Jun 7 2023, 5:47 AM · User-notice-archive, MW-1.41-notes (1.41.0-wmf.11; 2023-05-30), Growth-Team-Filtering, Growth-Team, Edit-Review-Improvements-RC-Page, MediaWiki-Recent-changes

Jun 1 2023

Mooeypoo added a comment to T202916: Stop changing my "Group results by page" prefs based on a URL that I've clicked on.

Previously, clicking on someone else's link to Recent Changes with filters applied within the URL, could unintentionally change your preferences for "Group results by page". This has now been fixed.

Jun 1 2023, 7:05 PM · User-notice-archive, MW-1.41-notes (1.41.0-wmf.11; 2023-05-30), Growth-Team-Filtering, Growth-Team, Edit-Review-Improvements-RC-Page, MediaWiki-Recent-changes

May 23 2023

Mooeypoo added a comment to T202916: Stop changing my "Group results by page" prefs based on a URL that I've clicked on.

How can we summarize what happens for someone who just land in this conversation? :)

May 23 2023, 3:51 PM · User-notice-archive, MW-1.41-notes (1.41.0-wmf.11; 2023-05-30), Growth-Team-Filtering, Growth-Team, Edit-Review-Improvements-RC-Page, MediaWiki-Recent-changes

May 19 2023

Mooeypoo added a comment to T202916: Stop changing my "Group results by page" prefs based on a URL that I've clicked on.

Okay, I have to admit, I completely didn't think about the option of only triggering the "save preference" when the user manually clicks the checkbox; I think in my mind I thought that the distinction (between explicitly clicking vs the programmatic change of state) wouldn't be as clear to users as to when the state is saved or not.

May 19 2023, 8:25 AM · User-notice-archive, MW-1.41-notes (1.41.0-wmf.11; 2023-05-30), Growth-Team-Filtering, Growth-Team, Edit-Review-Improvements-RC-Page, MediaWiki-Recent-changes

May 17 2023

Mooeypoo added a comment to T202916: Stop changing my "Group results by page" prefs based on a URL that I've clicked on.

In general, this approach makes sense to me and I appreciate having the preference configurable in the moment of interaction, rather than buried in Preferences. However, the "Do this from now on" button either isn't working on Patch demo or doesn't match my UX expectations. When I click on Do this from now on, I expect to receive confirmation that something changed.

May 17 2023, 8:55 PM · User-notice-archive, MW-1.41-notes (1.41.0-wmf.11; 2023-05-30), Growth-Team-Filtering, Growth-Team, Edit-Review-Improvements-RC-Page, MediaWiki-Recent-changes
Mooeypoo added a comment to T158725: RC page: Very long words cause horizontal scrolling.

This is still a problem for the RC/watchlist modes which use tables. I also don't really see a solution to that, which does not include "remove tables".

May 17 2023, 12:05 PM · MW-1.41-notes (1.41.0-wmf.11; 2023-05-30), MW-1.38-notes (1.38.0-wmf.12; 2021-12-06), Growth-Team-Filtering, Growth-Team, Edit-Review-Improvements-RC-Page, MediaWiki-Recent-changes
Mooeypoo closed T190980: Improve RCFilters highlight circles CSS code output and align due to new base font-size as Resolved.

This looks done to me, from 2018. Closing.

May 17 2023, 9:25 AM · Growth-Team-Filtering, MW-1.32-notes (WMF-deploy-2018-10-16 (1.32.0-wmf.26)), Growth-Team, Edit-Review-Improvements-Integrated-Filters, Edit-Review-Improvements-RC-Page

May 16 2023

Mooeypoo added a comment to T202916: Stop changing my "Group results by page" prefs based on a URL that I've clicked on.

It is never good to see a frustrated @Whatamidoing-WMF, and so in my explorations of RCFilters (in preparation for a planned hackathon project) I have decided to don my cape and try to help.

May 16 2023, 7:22 PM · User-notice-archive, MW-1.41-notes (1.41.0-wmf.11; 2023-05-30), Growth-Team-Filtering, Growth-Team, Edit-Review-Improvements-RC-Page, MediaWiki-Recent-changes

May 2 2023

Mooeypoo updated the task description for T332625: Architecture support for persisting client-side preferences.
May 2 2023, 8:42 PM · WMF-Architecture-Team

Apr 25 2023

Mooeypoo updated the task description for T333235: [Epic] Technical Decision Forum retrospective: Phase 1.
Apr 25 2023, 7:48 PM · tech-decision-forum

Mar 30 2023

hashar awarded T333235: [Epic] Technical Decision Forum retrospective: Phase 1 a Like token.
Mar 30 2023, 8:47 PM · tech-decision-forum

Mar 27 2023

Mooeypoo created T333235: [Epic] Technical Decision Forum retrospective: Phase 1.
Mar 27 2023, 8:54 PM · tech-decision-forum

Mar 20 2023

Mooeypoo moved T332625: Architecture support for persisting client-side preferences from Inbox/Watching to Now on the WMF-Architecture-Team board.
Mar 20 2023, 6:34 PM · WMF-Architecture-Team
Mooeypoo created T332625: Architecture support for persisting client-side preferences.
Mar 20 2023, 6:34 PM · WMF-Architecture-Team
Mooeypoo moved T329557: [EPIC] Create mechanism for persisting client-side preferences from Inbox/Watching to Now on the WMF-Architecture-Team board.
Mar 20 2023, 6:30 PM · WMF-Architecture-Team, Web-Team-Backlog
Mooeypoo added a project to T329557: [EPIC] Create mechanism for persisting client-side preferences: WMF-Architecture-Team.
Mar 20 2023, 6:29 PM · WMF-Architecture-Team, Web-Team-Backlog

Nov 2 2022

Mooeypoo updated the task description for T322253: Following Auth experiments.
Nov 2 2022, 6:43 PM · Authentication-Experiments-2022, WMF-Architecture-Team
Mooeypoo created T322253: Following Auth experiments.
Nov 2 2022, 6:42 PM · Authentication-Experiments-2022, WMF-Architecture-Team

Oct 19 2022

Mooeypoo added a comment to T313970: Next steps on Auth.

Tracking ticket from Security: https://phabricator.wikimedia.org/T297791

Oct 19 2022, 6:34 PM · WMF-Architecture-Team

Oct 10 2022

Mooeypoo added a comment to T312738: Adoption request for GraphQL.

Okay, I am now a Toolforge member. Just need @Mooeypoo to add me as a maintainer.

Oct 10 2022, 4:44 PM · Toolforge-standards-committee

Oct 5 2022

Mooeypoo added a comment to T312738: Adoption request for GraphQL.

Yeah, I think that's a good resolution.
I might need guidance as to what to do to make this happen...

Oct 5 2022, 1:44 AM · Toolforge-standards-committee

Sep 9 2022

Novem_Linguae awarded T145250: Consider requesting more notifications if the popup only has bundles a Like token.
Sep 9 2022, 12:01 AM · Growth-Team-Filtering, Growth-Team, Notifications

Aug 30 2022

Mooeypoo added a comment to T314871: Investigation: Determine approach for DST support.

I was thinking a lot about this ever since we talked about this problem, and so I would like to offer a slight point here about being careful of over-optimizing for this problem.

Aug 30 2022, 5:25 PM · Campaign-Tools (Campaign-Tools-Current-Sprint), Campaign-Registration

Jul 20 2022

Mooeypoo added a comment to T312738: Adoption request for GraphQL.

Unfortunately, I'm in the same boat; I've never actually been directly involved in the project. I had a very passing general interest in it while working on another GraphQL project -- and I worked with the original maintainer! -- but I don't think I can serve as a maintainer on this (or even fix bugs...)

Jul 20 2022, 9:47 PM · Toolforge-standards-committee

Apr 1 2022

Mooeypoo added a comment to T305091: [TypeaheadSearch] Support lang and dir attributes for text nodes within MenuItem component.

So a MenuItem can have a label, a match (e.g a Wikidata alias), and a description. This task covers supporting a lang and dir attribute for each of those things. It's clear to me what a MenuItem should look like in a purely LTR or RTL context. But what about the following scenarios?

  1. UI has one direction but all text nodes of a MenuItem have the other. For example, the UI direction is LTR but the MenuItem has an RTL label, match, and description. Should the entire MenuItem appear to be in RTL?
Apr 1 2022, 7:28 PM · Design-System-Team (Design-System-Sprint), Wikidata, Codex

Mar 14 2022

Mooeypoo added a comment to T300053: Bi-directionality: Documentation for RTL icons, components and patterns.

Feel free to share those wherever you deem fit :)

Mar 14 2022, 2:44 PM · Design-System-Team, Documentation, RTL, I18n, Codex

Mar 10 2022

Mooeypoo added a comment to T300053: Bi-directionality: Documentation for RTL icons, components and patterns.

@Mooeypoo thank you for your great and useful feedback, I have update the Figma file with the following:

Mar 10 2022, 2:44 PM · Design-System-Team, Documentation, RTL, I18n, Codex

Mar 9 2022

Mooeypoo added a comment to T300053: Bi-directionality: Documentation for RTL icons, components and patterns.

Another example for what I was trying to demonstrate is the "flipping" of the expected location of the negative sign

Mar 9 2022, 11:48 PM · Design-System-Team, Documentation, RTL, I18n, Codex
Mooeypoo added a comment to T300053: Bi-directionality: Documentation for RTL icons, components and patterns.

Can you provide some clarity/examples about what you mean when you say numbers with Eastern Arabic nuemrals are RTL'ed?

Mar 9 2022, 11:39 PM · Design-System-Team, Documentation, RTL, I18n, Codex
Mooeypoo added a comment to T300053: Bi-directionality: Documentation for RTL icons, components and patterns.

This figma file is absolutely incredible. For years we've been working on RTL support on the Wikimedia projects with some learnings and insights that were very rarely properly coalesced into a proper document with guidance and decisions, so having one being worked on not only as decisions for the specific Codex library, but as more widespread visual guidance is extremely helpful!

Mar 9 2022, 10:32 PM · Design-System-Team, Documentation, RTL, I18n, Codex

Feb 16 2022

Mooeypoo added a comment to T300053: Bi-directionality: Documentation for RTL icons, components and patterns.

Icons and RTL are one of my favorite topics of philosophical musings that lead to practical visual decisions -- but they're usually really complicated, as the discussion here demonstrates.

Feb 16 2022, 1:57 AM · Design-System-Team, Documentation, RTL, I18n, Codex

Jan 9 2022

Mooeypoo added a comment to T258578: In the "New video player" beta feature, Subtitle and Quality lists are forced to LTR direction.

Ok, applied bidi to some of the strings of TMH: https://translatewiki.net/w/i.php?title=Special:Translate&group=ext-timedmediahandler-user&language=he&filter=&optional=1&action=translate

We will see how that pans out exactly. Also still needs to be done for the other rtl languages of course and the patch is required as well.

Jan 9 2022, 8:40 PM · MW-1.38-notes (1.38.0-wmf.18; 2022-01-17), Video, RTL, I18n, VideoJS player

Jan 8 2022

Mooeypoo added a comment to T258578: In the "New video player" beta feature, Subtitle and Quality lists are forced to LTR direction.

@Mooeypoo if you have some time, i'd love to pick your brain on this.

I'd love to try, but this is an interesting problem... I admittedly did not have a chance to go over any of the code yet, so I'm mostly offering some guesses here for now based on previous experience.

Jan 8 2022, 11:16 PM · MW-1.38-notes (1.38.0-wmf.18; 2022-01-17), Video, RTL, I18n, VideoJS player

Dec 15 2021

Mooeypoo added a comment to T293704: Deploy current main branch's docs site to doc.wikimedia.org.

Not only is netlify self hostable, it directly connects to a github repository and gives you a myriad of deploy tools, including an automatic pull request preview, A/B testing with two or more branches, deploy out of a specific branch, etc.

Dec 15 2021, 7:13 PM · Patch-For-Review, Continuous-Integration-Config, Design-Systems-team-20200324-20220422 (Design Systems Team FY2021-22 Kanban Board), Codex

Dec 2 2021

Mooeypoo added a comment to T296908: Add image - image inspector flips filenames for RTL .

Ah, localizing filenames on wiki, yes. One of the toughy questions, honestly.

Dec 2 2021, 5:09 PM · Patch-For-Review, MW-1.39-notes (1.39.0-wmf.10; 2022-05-02), Growth-Team (Sprint 0 (Growth Team)), Image-Suggestions

Nov 15 2021

Mooeypoo added a comment to T295189: Ensure that Codex CSS supports both LTR and RTL directionalities .

(Add) -- also, you'll need to take into account the ability to let component users (implementers?) force directionality for content (so, input direction regardless of interface) and also force and set based on interface. I know we all know this, I'm just pointing it out because it might get a bit more complex with the prefix selectors.

Nov 15 2021, 7:28 PM · Patch-For-Review, Design-Systems-team-20200324-20220422 (Design Systems Team FY2021-22 Kanban Board), I18n, RTL, Codex
Mooeypoo added a comment to T295189: Ensure that Codex CSS supports both LTR and RTL directionalities .

This sounds generally good plan, I'm slightly worried about how exceptions may work with logical properties, but I think they should work in general.

Nov 15 2021, 7:26 PM · Patch-For-Review, Design-Systems-team-20200324-20220422 (Design Systems Team FY2021-22 Kanban Board), I18n, RTL, Codex

Sep 13 2021

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

My point here is that I think these are brilliant questions not only about "a knowledge store" -- but about what is our content, and how we are going to even consider the delivery *and editing* of the content we have if we want to try and display it as more than "just" one-big-web-page.

I definitely agree, this is the crux of the problem. To me there are two open questions:

  1. Are there abstract, philosophical if you will, answers to these questions?
Sep 13 2021, 10:24 PM · tech-decision-forum

Sep 3 2021

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

There's a lot of really good questions in this thread that are more about the general knowledge store than they are specifically about the data model (so just pointing out potential scope creep of the ticket specifically regarding the DSO) *but* I have some general points that I thought would be useful to raise in this context too.

Sep 3 2021, 6:55 PM · tech-decision-forum

Aug 11 2021

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

If the question is "do we need a data model in general", my thoughts are a bit more generic:

  • I do not think our problem is the lack of data models, I think we already have too many and all of them are different. We have a lot of various API families (action, rest, restbase etc), we have events, we have recent changes streams, etc etc etc - all of these are different ways of consuming knowledge in the structured way. I am worried that adding one more data model will just make us end up with 15 different standards instead of 14 unless we are very bold and we claim that "this is the one, all the rest are deprecated, we will spend Herculean effort and standardized all of our existing knowledge consumption points". Is the new thing being proposed as a replacement for everything we've got so far or is it yet another thing?
Aug 11 2021, 10:38 PM · tech-decision-forum
Mooeypoo added a comment to T284258: Knowledge store data model.

Another clarifying point is that this isn't about changing our internal nomenclature "deep inside our stack" - this is a solution that's meant for clients like Wikimedia Enterprise and a distribution method to provide a layer between the information we have in our databases that uses terms and nomenclature that are very specific to the Mediawiki operations, and translate that to consumers who want to digest pieces of the data using as much commonly "human digestible" terminology and structure as possible.

Aug 11 2021, 10:21 PM · tech-decision-forum

Jul 7 2021

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.

Jul 7 2021, 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-System-Team, Codex, CSS

Jun 14 2021

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

(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 · Patch-For-Review, Editing-team, 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.
In T284783#7150445, @APerson wrote:
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 · Patch-For-Review, Editing-team, 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 the new Vue component library.

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

May 26 2021, 12:43 PM · Design-Systems-team-20200324-20220422 (Design Systems Team FY2021-22 Kanban Board), WVUI
Mooeypoo added a comment to T282835: Evaluate use of TypeScript in the new Vue component library.
  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-20200324-20220422 (Design Systems Team FY2021-22 Kanban Board), WVUI

May 14 2021

Mooeypoo added a comment to T282835: Evaluate use of TypeScript in the new Vue component library.

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-20200324-20220422 (Design Systems Team FY2021-22 Kanban 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 · RTL, I18n, 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