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.

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...)

In T305091#7822743, @AnneT wrote:

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?

Feel free to share those wherever you deem fit :)

In T300053#7767004, @bmartinezcalvo wrote:

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

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

In T300053#7766024, @Huji wrote:

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

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!

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.

In T258578#7607627, @TheDJ wrote:

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.

In T258578#7607375, @TheDJ wrote:

@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.

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.

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

(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.

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.

In T284258#7350064, @Milimetric wrote:

In T284258#7331791, @Mooeypoo wrote:

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?

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.

In T284258#7277277, @Pchelolo wrote:

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?

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.

In T284783#7200660, @Tacsipacsi wrote:

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.

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.

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

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.

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.

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"

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".

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)

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?

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.

In T284783#7150445, @APerson wrote:

Previous discussions:

• https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Countering_systemic_bias/Gender_gap_task_force/Archive_10#Adding_template:gender_to_the_editing_toolbar_or_something%3F
• https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(idea_lab)/Archive_18#The_personal_pronoun_problem
• https://en.wikipedia.org/wiki/Wikipedia_talk:Tools/Navigation_popups/Archive_10#Proposal_to_integrate_gender_preferences_into_Navpopups

Open to suggestions on what should be shown instead, if anything. By default, will follow whatever the Reply Tool decides on.

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.

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

In T282835#7111640, @Jan_Dittrich wrote:

2. 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).

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.

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

Re your notes, in reverse order:

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

In T265080#6531249, @Huji wrote:

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.

In T265080#6531249, @Huji wrote:

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:

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")

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.

In T258935#6509665, @IKhitron wrote:

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.

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.

In T258935#6506386, @DannyS712 wrote:

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?

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.

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

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.

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.

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)

In T255504#6266193, @dbarratt wrote:

@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).

@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.

Another idea, followup from conversations in the team:

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.

In T249259#6158741, @Krinkle wrote:

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

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

In T249259#6148287, @dom_walden wrote:

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:
   
3. Click the watch star again. You will see the usual unwatch message:
   
4. Click the watch star again. You will see the special StructuredDiscussion message:
   

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):
   

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.

In T249259#6150283, @Krinkle wrote:

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.

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.

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.

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

In T217363#6103219, @Prtksxna wrote:

In T217363#5860532, @DannyS712 wrote:

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?

In T251894#6108725, @Tchanders wrote:

Tagging @aezell in case manager approval is needed.

@Mooeypoo do you need access too?

In T251590#6100879, @Volker_E wrote:

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.

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.

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.

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.

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

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

Split to two tickets:

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

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

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

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.

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.

In T246958#5950354, @Tchanders wrote:

@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.

Thank you for the thorough analysis, @Tchanders !