I have done so, as a test. When a user wants to create an account, the URL 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.

@Lydia_Pintscher Strange server error? Who can solve this? The application ListeriaBot has stopped since 8 Februari... GLAM projects are using this tool a lot to organise edit-a-thons...

@Magnus - As per http://magnusmanske.de/wordpress/?p=650, bugs should be registered only via https://github.com/magnusmanske/listeria_rs/issues, and no longer via https://bitbucket.org/magnusmanske/listeria.

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

1. I believe my script is actually solving T282719, and I have been taking care to implement the required data quality rules (only loading validated data, not creating duplicate statements). The other tasks are loosely related to ISBN, and could be omitted from the script, when you feel the need.
2. The mainlang global variable is indeed the default description language, when the ISBN digital libraries would not return a language value. It determines in which language the label is written when creating a new instance. Therefore it is important to group ISBN numbers by language when exececuting the script, to ensure creating the label in the correct language. It is also used to search for items, and for displaying properties and items in the user language.
   • I would propose that you reinstate the original code line inputfile = sys.stdin.read(). This allowed to run the script for 1000s of ISBN numbers, when needed, on multiple lines (e.g. the full references section of any Wikipedia page containing ISBN numbers, via regex).
   • You changed it into: inputfile = pywikibot.input('Get list of item numbers'), which basically allows to process only 1 single ISBN number (one single input line), which I don't find a good solution...
3. I am currently working on "Known problems" like ensuring the inverse relationship between "Written work" and "Edition", making sure that the "Is a written work" and "Edition" statements exists at the level of Written work.
   • Other known problems can't be solved by the script, because they are caused by external, or complex internal data quality problems, and should stay. Examples: a Publisher is not found, because the statement "Is a publisher" was not assigned to its item.
   • Some other known problems could be moved to "To do", when they would require additional development.
   • I would personally want to add here another interesting functionality: "Implement a webservice on toolforge.org, based on the current shell script", accepting input from a textbox instead of from stdin.
4. The documentation links could be split into specific or general documentation (the general, non script specific documentation could also be removed -- I included it for myself to easily find the documentation).
5. The environment restrictions are indeed common for all Pywikibot scripts, so could be left out of the script.
6. Since I am still the only author at https://github.com/geertivp/Pywikibot I have changed the license to MIT. So you can change the license to MIT in the source code as well.

I have uploaded https://gerrit.wikimedia.org/r/c/pywikibot/core/+/826631

Thanks, @Xqt. I believe I might use https://gerrit-patch-uploader.toolforge.org, as a first step? In this case I do not need to install additional tools and learn complicated commands? I might later use the more advanced tools, once I get more experience?

I have an account on Gerrit, but I have never used it... if you could provide me with a "next step", this would be great... Thanks for your support.

If you believe my script is good enough, I would be delighted that you assist me?