This was a mistake in I53c0283, sorry. There are two users involved:
The "agent" is the user (typically an administrator) that made the
user group change, while the "viewing user" is the user for which the
user group was changed. When the "agent" moves the "viewing user"
into a new user group, the "viewing user" is the one that's now
a member of that group. They are what dictates the gender for the
"group-…-member" message.
Is this mistake bad enough for a backport?
Bug: T368249
Change-Id: I4916de2fb171873b625e51ee8823811e0296d323
This affects primarily the message
"notification-header-user-rights-add-only" which is very priminently
seen by every new editor that made their first few edits and gets
promoted to the next user group a few days later. Turns out the code
was just incomplete. All the information about the user and their
gender is already there, it was just not forwarded correctly.
Notice there are two messages:
* "group-…" messages don't have gender support. This is the (ideally)
gender neutral name of the group. Meant to be used as e.g. section
heading for a list of users.
* "group-…-member" is the same with gender support. To be used in all
contexts that are about a single, specific user with known gender.
Which is exactly what's happening here.
Turns out we can even use a neat convenience function from the
Language class that does exactly what we need.
I can't tell why but the array_values is apparently critical.
Originally added via I49b5fe5. It can't hurt so I keep it.
Bug: T368249
Change-Id: I53c028375d77c93f399538fd38aa8f8af30934b0
The duplicated parameter $6 is unused since 2016, see Iabeaae7.
Nothing is left that uses the parameter. I also checked for local
on-wiki overrides via GlobalSearch.
Bug: T368249
Change-Id: I8a5975347756f2fd5f5e065112ddc38d829e89ed
There is no guarantee the MediaWikiServices instance is still valid.
Other tests can reset it.
Bug: T368390
Change-Id: I92de60b2ba5fb66af957a800ce85773db58303cc
This is a copy-paste mistake from the message directly below.
Happened in Ibe0092a not long ago.
Also add some comments to make it easier to find the places where
seemingly unused messages end being used.
Bug: T368249
Change-Id: I709c0f14978daad8c98f1f8edf52ef28029c6d40
The main motivation here is to make these messages easier to
localize. The English versions aren't necessarily wrong, but a bit
ambiguous and hard to localize in languages like German where the
word "user" needs to be gendered.
Note these are error messages.
Change-Id: I76d58120e86730ee69216a87349b08f94e7b979e
The main motivation here is to make this easier to localize. For
example, in German the word "user" needs to be gendered depending
on the user's preference. But the user name appears only much later
in the sentence, after "of". It appears like this can easily be
improved and even the original English message reads better then,
doesn't it?
Change-Id: I055481edbd572334bd2fffdcad9da67376ca5464
I believe that saying "my talk page" is canon and really more than
enough. Even less confusing, especially when compared with the other
messages that talk about "my user page".
An additional motivation here is to make this easier to localize.
This turns out to be especially relevant in languages like German
where "user" needs to be gendered. We can avoid this here entirely.
Change-Id: I6588032d2b54e3729200c3342d668fc445f46312
Use the max width breakpoint from wikimedia-ui-base
to add or remove popup container padding. That is
because the container has no padding in small
screens (when Vector's header breaks in two rows).
Bug: T366672
Change-Id: Idb0f844189cc221009cbb3e06c8c3fe0096bd0c2
This was broken when replacing `$.extend` by `Object.assign` in
I1e603647c161bf940690f85f676edd7ebde7917d (commit 47ea647).
`Object.assign` fails when the first argument is `undefined`, but
`$.extend` doesn't.
Bug: T368029
Change-Id: I13025a783c7f4d173dce096efa47f659273f0dd5
Also write the callable as one string in extension.json,
the newline makes it hard to read as callable.
Change-Id: I6e670907aa36effa4b9485fafbb59918d62e2f2a
