As an urgent workaround, please add a search-label "Case sensitive search keyword" instead of just "Search keyword"-- this way users will be aware of the bug/restriction. Now users don't find events, but they are not aware why. Just adding to the label "Case sensitive" is peanuts, and costs nothing.

How to invoke the problem:

• start a private browser session (having no session cookie)
• try to login

It seems that the original error still appears when the user does not have an active Wikimedia session.

• Activate the Wikidata CiteTool Gadget
  • Add a caption at the Wikidata item statement reference

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

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

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.

Basically a user should be able to easily choose or change their "home wiki". Specifically the Outreach dashboard, when creating the user account, the system should take the "Home Wiki" as per the event, and not /enwiki/ as the only hardcoded platform. See also T307878 for a similar complaint. I agree with the above that the home wiki should allow to see on which platform/Wikipedia a user wants to be contacted via e.g. a user discussion page.

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

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.

See T416246

Thanks for fixing the database category loading problem.

I understand that the phonetisch package is external to Pywikibot, but we should be able to have a correct library to encode caverphone strings using Pywikibot.

Please disable this useless WARNING: entity-schema datatype is not supported yet.

Same problem here...
Even replacing /// by %2f%2f%2f produces the same error...

Also read T248632

Something simple like --[[User:MyUserName|]] should work on all Wikis. The "User" namespace is recognized on all Wikis, and is simple to type by the users... no need for complex templates like {{ns:User}} ?

Thanks for investigating. Three further questions:

• Strange that I didn't find ticket T110489 when I searched for "browser language" before having created T405144? Still now I don' t find ticket T110489 while the words "browser" and "langugage" are clearly in the titel...
• Shouldn't ticket T110489 be merged with T5665? (that is an unsolved issue from 2005!)
• What about T58464? (from 2015)

I believe our readers expect and should be granted content in their own language, without requiring them to create a user account, and logging in...

I only activated the GoogleTrans Gadget on wp.nl; therefore the problem did not occur on other languages.

Effectively, I can confirm that behaviour:

• the problem disappears when I disable the GoogleTrans gadget
• It only occurs after using the Shift-key, e.g. the [ ] square brackets do not need the shift key

It is strange that e.g. the Edge browser, also based on Chrome, does not show the isssue.

Correct, I also encountered this BDI tag problem when pasting in VE from https://outreachdashboard.wmflabs.org to a Wikipedia main namespace page. Workaround: paste using Ctrl-Shift-V (unformatted).

I have tested with other browsers. I don't have the problem with Firefox, nor with Edge. I only have the problem with Google Chrome and Opera.

It happens on https://nl.wikipedia.org, when replying to a discussion topic, either in Visual or Code editor mode. When typing text containing ~!@#%$^&*( )+"{ }< >? or other nonalphanumeric symbols anywhere but the start of the text, the right-to-left modus and inserting typed text at the very start of the line begins.

Strange: The creator of the original page, User:MichellevL (WMNL), did have the Event organizers right, but still the event registration could not be enabled, by somebody else, also having the Event organizers role.

I believe if somebody with Event organizer role would use the link Special:EnableEventRegistration, the application should grant the tole of the "enabler of the event" instead of the refusing the page creator, not having the organiser role.

How does wp.fr show my username?
https://fr.wikipedia.org/wiki/Wikipédia:Accueil_principal

For info: https://help.openai.com/en/articles/8912793-c2pa-in-dall-e-3

I understand that MediaWiki core functions in this context have a negative impact on cache performance.

I would like to have/use a "magic word" (template/function) to get the username of the account that is currently logged in -- to be able to use it as a parameter/suffix in a semi-dynamic URL.

The Campaign dashboard is frequently not available. This disturbes both participants of edit-a-thons, and even more the organisers, because they are accessing the platform a lot.

I confirm that the times are identical now, if I am logged in versus when browsing in a Private window (not logged in). Thanks for updating the Event tool.

It would already help if the list would be sorted ascending by name, and descending by version? Then the user can easily weed through the list, and remove any (for them) obsolete versions.

Sorry to insist; is there any technical or operational reason why Special:MyEvents and Special:AllEvents (that are part of MediaWiki) can't use the general CirrusSearch and Elasticsearch logic, that is used to index lemmas (article names) and article Wiki text (article content)? As a user I don't see the difference between an article title and an event title. As I understand it, Elasticsearch is used for all namespaces, but not for the Event namespace?

I try to understand why case insensitive search would be such a large problem? E.g. all WikiMedia applications, including Wikidata, support "ignorecase" search?

See also T356153, a request to show the Wikimedia Outreach Dashboard with related ongoing projects. That request might be outdated by the current request, because the Wikimedia Outreach Dashboard is typically at the backend of the new Events tool... identifying contributions of participants to an event.

I have uploaded a new version to GitHub (bug correction, enhanced error messages).
https://github.com/geertivp/Pywikibot/blob/main/create_isbn_edition.py

You can find the latest version in https://github.com/geertivp/Pywikibot/blob/main/create_isbn_edition.py.
I need to find time to merge it again into Gerrit.

I continue to work on the script.

I believe this has been implemented? Please confirm.

I believe it should not be too complicated to extract metadata from a PDF file. When viewing a PDF file, external from Wikipedia, and clicking on File properties, we generally see the title, the author, the creation date, etc. as standard properties. Mapping this data onto Citoid standard reference attributes should be obvious.

The event removal button problem is now solved due to the implementation of T363187 - thanks for that!
But the reactivation functionality is still pending in T318412.

I have been able to remove the event banner from the page. This solves the problem of users not being able to register due to the sync problem. Thanks for fixing this.
Now there is something else: to my opinion it should always be possible to add the event banner again, the same way as when the event page was initially created. I can see no reason why this would not be allowed.

As a user, I have implemented a temporary workaround to permit the participants to register straight via the Outreachdashboard...
but please continue to implement the different bug fixes...

I can indeed confirm; when I attempt to delete the event, I get the following error:

The course Amazone/International_girls_in_ICT_day_(2024-04-25) is not connected to this event, and therefore it cannot be synchronized.

Delete event registration -
Confirm that you want to delete this event registration by using the "Delete" button. This action cannot be reverted.
(Delete-button)

Still a problem with https://meta.wikimedia.org/wiki/Special:RegisterForEvent/480 -- see the following error message. It seems that the link between the Event and the Dashboard is broken/lost.

OK, I understand now.

That is the whole point... the user is not interested in UTC time; the user should read his/her own time; the system should add the browser timezone... not the user...

Why not adding the timezone difference immediately to the GMT/UTC time, so the local time can be displayed to the user directly... can be drived via a JavaScript: see https://stackoverflow.com/questions/1091372/getting-the-clients-time-zone-and-offset-in-javascript

This is exactly the problem. When the user is not logged in, the browser timezone should be taken into account, instead of displaying just the UTC time. The user should not be required to manually recalculate the time.
There exists a JavaScript function to do so: https://stackoverflow.com/questions/6939685/get-client-time-zone-from-browser

The problem being yesterday solved... today I thumble into another problem:
http://192.168.1.42/wiki/index.php?title=Parsoid&veaction=edit

{"messageTranslations":{"en":"The requested relative path (/v3/page/Parsoid) did not match any known handler"},"httpCode":404,"httpReason":"Not Found"}

I was able to solve this problem on an existing MW 1.35. The problem unexpectedly occurred after an upgrade from Linux Mint 20.3 to 21.3, which involved an upgrade from PHP 7.4 to 8.1. The Visual Editor worked well with PHP 7.4 but systematically failed on 8.1.

This is equivalent functionality delivered via xtools:

I have done some more research. The following code works for all browsers, and is better recognised by the Visual editor:

This problem seems to exist already since 2008 in Firefox... time to fix...

Problem had already been logged on 2023-09-27 via https://github.com/magnusmanske/listeria_rs/issues/109. Why does it take 2 days to resolve the operational problem?

Problem was resolved since 2023-09-29 11:30. Can anybody document the solution?

I can't remove the duplicate campaigns. In addition, I can't get the category updated. The campaign list stays empty. Possibly caused by the duplicate campaigns using the same category?

• https://commons.wikimedia.org/wiki/Commons_talk:ISA_Tool#Wrong_error_message:_Error_creating_campaign

As an alternative, the polling system could use the Wikipedia where the user has the most contributions.

Technically, the Home is frequently (and often wrongly) set to the English Wikipedia, because new accounts e.g. created via the Events & Progams dashboard are always created on the English Wikipedia, while the user is possibly most of the time active on other Wikipedia language's. Therefore tools should create the account on the correct Wikipedia language. I have filed T307878 for this problem.