In addition to that, if the browser is not set to the native user language correctly, the user can still change ones language interactively in the Outreach application. Then the application should login to this specific language Wikipedia, often different from EN...

Thanks @Geertivp! I agree that this would be a good improvement. Unfortunately, the OAuth library that we use to handle the login process was written with the assumption of using a single MediaWiki instance for login, so it would take a significant rewrite of that library or some creative workaround to make it possible to make the login flow work based on browser language.

See also https://meta.wikimedia.org/wiki/Talk:Programs_%26_Events_Dashboard#Non-English_users_are_confused_when_requesting_or_creating_a_user_account

I can support this request. See also https://meta.wikimedia.org/wiki/Talk:Programs_%26_Events_Dashboard/Archives/2024#Request:_Automatic_account_creation_on_home_wiki? as another sample case from a while ago.

There are two practical reasons why I think this is important to fix:

• the choice of project determines the language of the form. Not everyone speaks English.
• English Wikipedia has a different account creation policy than other wikis. Organizers of an event in nlwiki may have ways to request exemption status there, but if the account is created at enwiki, that doesn't work.

Not that this couldn't be useful, but what "doesn't work"? If a SUL account exists it can be granted exemptions on local projects.

Thanks for asking!

After reading the above, maybe a few links and screenshots may also be helpful. Sorry if this feels like I'm going overboard :) The specific sub-case that I'm concerned about is this:

• I organize an event. For example, an edit-a-thon. Now I should tell my participants to enroll. Example: https://outreachdashboard.wmflabs.org/courses/test/testNL

• I send them the dashboard-provided link, because that links their accounts. This would be https://outreachdashboard.wmflabs.org/courses/test/testNL?enroll=chjqaoty
  • I might do this in advance (language problems below, rules confusion etc apply even more)
  • I might do this in person, on location (account creation limit applies)
• Open this link incognito.

• This page will welcome you as a new registrant for the course. I get an option to log in or to create an account. Choose create account.

Maybe this is easiest visualized if you imagined the situation reversed: everyone would be sent to the Arabic Wikipedia. (sorry Arabic friends, nothing against you!)

• That link always sends you to the interface in a different language than the event or the wiki you're trying to edit (currently the dashboard does not overrule the locale).

• That page has the Enwiki rules for what usernames are permitted, so you'll have to be able to process them, and actually understand them as an organizer that didn't expect this. This may result in a filter not accepting your account choice (I'm actually not even sure I fully comprehend the implications of this part). For example, that link on the top left above the username is to the username policy. That sends you here:

• This wiki has different IP-ranges blocked, because they expect their editors to come from different places than the wiki you're trying to work on. Let's assume the organizer did their homework and checked their local wiki. They may even have received a local exemption for their event for the block. Unfortunately, this doesn't seem to work now (from what I understand, enwiki blocks are applied? Someone please confirm!) Note that block messages etc are also in the wrong language.
• The organizer may have been very rigorous, and applied for account creation limit exemption on their local wiki, but now it turns out... this exemption doesn't work on English Wikipedia. So after 5 accounts, they're stuck. A colleague was giving me some examples today where she actually ran into this problem and was lucky enough to know of a workaround for those specific users, but this won't always work out.
• Finally, I would be worried about potential blowback if someone were to organize an edit-a-thon with new contributors in, say, Javanese Wikipedia and people are forced to create an account in Dutch. I am not sure there are some examples where this might also be a problem with English - but it may leave a bad taste when you're trying to focus the event on non-majority languages for example.

In summary: you're right to a point that you could probably work around most of this, if you know it's going to happen, with enough preparation and if you have sufficient friends in English Wikipedia admin world. However, two things remain a problem, especially if the link is sent in advance without physical presence.

This does work from the assumption that the enwiki blocks and exemptions are the ones that apply - which is what I've been told, but can't verify easily myself. My apologies if this is incorrect!

I appreciate that the fix is apparently not straight forward. But if you are unable to create an account in the first place, SUL won't be helpful to work around it.

Thanks, @Effeietsanders, you clearly describe the problem! The Wiki platforms should respect the local language and not force all parts of the world to create their user acccount on en.wiki ! Also the "home wiki" should always remain the local language wiki. I really can't understand why it is technical difficult for the backend system to use the right language wiki for account creation? Why does en.wikimedia.org seems to be hardcoded? It is really complicating the account creation on our edit-a-thons. A typical place where newbees are confronted with a total confusion, also in combination with IP address blacklisting, and the account creation daily limit. We are often loosing 30 minutes before everyone has got a user account. Therefore I request all participants to create a user account at home; but several participants did not do it, or do find it too complicated. This problem really must be solved.

I know the dashboard-created accounts are already bypassing ratelimits and has enwiki ipblock exemption. Is it actually failing to create accounts still? I agree this isn't ideal; just trying to what the biggest blocking issues are. One I can see is if there is a global block, the local project may need to exempt the users locally so they can contribute, but that would happen even if they were created locally.

I believe you don't understand the users' problem. A user editing on a non-English wiki get its user account created on the English Wikipedia, and then can't login to the local language wiki because there is a problem that the account doesn't locally exist... also problems with cookies, etc. very complicated for the user, but to my opinion should be easily solved when the account is created on the language wiki the edit session is targeted on. Please step away from the English wiki viewpoint... e.g. a Wolof user doesn't understand English...

OK, what is it that is preventing the account from existing locally? If it is a block that an admin would have dealt with they still can.

In T307878#11612828, @Xaosflux wrote:

I know the dashboard-created accounts are already bypassing ratelimits and has enwiki ipblock exemption. Is it actually failing to create accounts still? I agree this isn't ideal; just trying to what the biggest blocking issues are. One I can see is if there is a global block, the local project may need to exempt the users locally so they can contribute, but that would happen even if they were created locally.

Lets come up with a test that we can run locally without organizing an event and make sure that this is still a problem. Would this work? (if it has a letter, we only execute it in that route)

• Create an event on nlwiki
• Get a VPN connection
• Get the IP address
• A: Ask a steward-friend to temporarily global-block that address
• A: Ask a local nlwiki admin to create an exempt for that address
• B: Ask an enwiki admin to block the ip address, and verify it's not blocked on nlwiki
• A/B: Try to create an account
• A/B/C: Try creating 10 accounts

In your idea should this work? What would your expected behavior be in route A, route B, route C?

As a sidenote:
Just to be clear, the biggest blocking issue is really that the /enwiki/ in the url should become /<homewiki>/ . That may require a bigger change that also involves the API somehow, but that is a 'true solution'. However, I can indeed imagine that there might be workarounds available to deal with some of the symptoms - which is also appreciated!

Seems like the only part of a test you need is "can the dashboard create requested accounts" when the requester is on a blocked address? Once the SUL account gets created it's not a dashboard issue anymore. Regarding what SUL shows as the 'homewiki', yes that would require a change - but also SUL homewiki's are really that important.

All that being said, for this task - I suspect this request is a duplicate of T126288 - is there anything new here?

In T307878#11613091, @Xaosflux wrote:

OK, what is it that is preventing the account from existing locally? If it is a block that an admin would have dealt with they still can.

The fact that /enwiki/ is the single hardcoded homewiki in the Outreach dashboard create account function. As if there are no other languages in the world beyond English? The Outreach dashboard create account function does never take into account the home wiki as documented for the edit-a-thon.

OK, I did a test with the help of an enwiki admin. Reproduction steps:

• Go to https://en.wikipedia.org/wiki/Wikipedia:Get_my_IP_address and copy your IP
• Open incognito browser and go to nl.wikipedia.org and create an account . Confirm this is possible. Close browser.
• Open incognito browser and go to en.wikipedia.org and create account. Confirm this is possible, close browser.
• Open the event registration link in an incognito browser and click on "sign up with Wikipedia". Observe that this is possible. Keep this window open.
• Block your IP on en.wikipedia.org for 30 minutes
• Open the event registration link in an incognito browser and click on "sign up with Wikipedia" --> observe that this link is now greyed out with a subtle 'information' icon that tells you that the IP is blocked.
• Now we return to the already opened window. Note that the url has something like /enwiki/ in it. Try creating an account. Observe that you get a message with: "Auto-creation of a local account failed: This IP address has been blocked from editing Wikipedia."
• Go back to the same url and change /enwiki/ to /nlwiki/ and try again. Observe this still gives the same message.
• Open incognito browser and go to nl.wikipedia.org and create an account . Confirm this is possible. Close browser.
• Open incognito browser and go to en.wikipedia.org and create account. Confirm this is NOT possible, close browser.

As you can see, it looks like that the mediawiki account creation that this is using, is using the enwiki block list.

It looks like that changing the 'wiki' would in fact not help. It may or may not help for some of the other concerns listed above. It may have to be fixed elsewhere.

As a sidenote: the 'information' blob that you see when blocked, is below. This message is unclear whether it's a block or an account creation limit, which explains confusion in reports. That suggests however that a) account creation limits from enwiki still apply to this outreach dashboard approach, b) the local (nlwiki, arwiki) account creation limit exemption that organizers assume to be helpful, are indeed not helpful, and enwiki exemptions are needed instead...
{F72046008}

This doesn't seem like you are using the dashboard to create accounts, and are trying to create them directly on the project. Have you tried using the dashboard account creation process?

In fact, this is using the account creation link that the user is presented with on the dashboard registration page. Maybe I'm misunderstanding your assumptions/question? I added a screenshot below of what the attendee would see.

{F72046452}

To be superfluous, I also tried creating an account via the 'add editor' button (not sure if this is the expected workflow, the interface is a bit confusing here):

@Effeietsanders "Add user" only allows the event coordinator to register existing users to the Outreach dashboard session; it does never create user accounts.

In your event, turn on account requesting.

I have done so, as a test. When a user wants to create an account, the URL prefix becomes https://auth.wikimedia.org/enwiki/wiki/Special:CreateAccount. Remark that enwiki is used in the URL, while the home wiki is nl.wikipedia.org. So the account is created on en.wiki. When the IP address of the edit-a-thon site is blacklisted on the nl.wiki the user is refused to login, because the session cookies are not OK as the account was created on the en.wiki where the IP address was not blacklisted...

Another reason to create the user account on the home wiki, as registered in the Outreach dashboard program.

Remark also, that Outreach dashboard account request is not available when Event registration is activated and linked with the Outreach dashboard. In that case the user can only create ones account directly on the Wikipedia where the event is organised.

I was unable to verify the blocking and exempt status for the admin account creation.

I also learned that changing to enabling 'request account creation' seems irreversible - after that the 'create account via Wikipedia' is no longer available.

I still think that because of all the reasons listed above, it is desirable that the user can have the account creation themselves, without having to rely on an admin to approve this (which is overhead that might be nice to avoid, and required synchronisation).

The oauth app seems registerd for all projects, its' just that at https://github.com/WikiEducationFoundation/WikiEduDashboard/blob/876e7458aac78e7003f084531bb6e507ed6fc200/config/initializers/devise.rb#L284

They hardcode english wikipedia as the signup and login destination here..

But if I manually manipulate the generated link that i'm being directed to (retaining the generated returnto for the oauth query part), so that am directed to nl.wikipedia for login and create account, this just works. I DO notice that after login and create account, i'm redirected to en.wikipedia.org for the OAuth application approval step. This is because my oauth request was initiated with this domain i'm assuming.

@Ragesoss said:

Unfortunately, the OAuth library that we use to handle the login process was written with the assumption of using a single MediaWiki instance for login, so it would take a significant rewrite of that library or some creative workaround to make it possible to make the login flow work based on browser language.

I'm not entirely sure why this would be.. is it because the session stuff that omniauth does cannot handle this? or because the omniauth is some sort of singleton or something that we cannot properly initiate with the correct information?

If it is really problematic to modify, can we just manipulate the generated url that we put into the page, before we send users there, so that en.wikipedia.org is replaced with the proper wiki for createaccount/login and then the en.wikipedia.org is still used for the omniauth generation and return ? Then at least the f T126288 part would still be fixed.

One thing to keep in mind, we did a special workaround with the English Wikipedia so that mass registrations that run in to rate limits otherwise don't hold up this process. (See processing here: https://en.wikipedia.org/wiki/Special:Log/OutreachDashboardBot ) .

If creations are going to move elsewhere, consideration for that workflow will need to be made.

In T307878#11710094, @Xaosflux wrote:

One thing to keep in mind, we did a special workaround with the English Wikipedia so that mass registrations that run in to rate limits otherwise don't hold up this process. (See processing here: https://en.wikipedia.org/wiki/Special:Log/OutreachDashboardBot ) .

If creations are going to move elsewhere, consideration for that workflow will need to be made.

But those are for when the manager of the campaign creates the account for the person right ? That doesn't influence either of these workflows I think... these all link directly to Special:CreateAccount, so that's when you make the account yourself, and the bot isn't involved in any of that i think.

TheDJ to the best of my knowledge, that is only triggered when the facilitator processes the dashboard requested accounts. My note was just calling out that there seems to be a different hard-coded processes that goes to enwiki there.

In T307878#11709728, @TheDJ wrote:

@Ragesoss said:

Unfortunately, the OAuth library that we use to handle the login process was written with the assumption of using a single MediaWiki instance for login, so it would take a significant rewrite of that library or some creative workaround to make it possible to make the login flow work based on browser language.

I'm not entirely sure why this would be..

It's mostly irrelevant, as we need to migrate to OAuth2 anyway, so we'll be moving off that library and likely won't need an intermediate mediawiki-specific library. I expect to do that sometime this year.