Problem solved due to T363187 - thanks!

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.

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?

Correction

The problem occurred again, unexpectedly... strange...

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

Real-live example of a manual correction after the valign="top" was lost:

• https://be.wikimedia.org/w/index.php?title=Newsletter/2022-03&type=revision&diff=18893&oldid=18892&diffmode=source

I believe that the error might also occur when switching back and forth between the Visual editor and the Tag editor?

Another issue was typing a #REDIRECT [[xxx]] in the tag editor that generated <nowiki>#</nowiki>REDIRECT [[xxx]] (obvisouly wrong) when the code was immediately saved.

I believe that Education-Program-Dashboard might be a better tag... (already present) -- so you might remove Outreach-Programs-Projects?

I would propose to add a parameter "level=1" to the Special:PrefixIndex to e.g. limit the list to the first level (main subpages); level=2 would also show the sub-subpages, etc. When there are too many sublevels an unrestricted subpage list confuses the users. Then we could have the same list generating statement on the next sublevel, etc. making it more easy to easily navigate through subpages.

Why are we waiting to implement this easy solution to have inline citations after a bullet point? I can't motivate this missing functionality to participants of Wikipedia writing sessions...

You might choose to only implement the User page and the User talk page link (which are the most important). Sending an e-mail could be done indirectly via the User edits page; and this is only available for users that have activated their e-mail address. This would require only a single additional click.

Unwanted <nowiki> tags and line spacing are also generated when pasting wiki text in the Visual editor using Google Chrome Control-Shift-V (paste without formatting).

Thanks, it was not clear to me what "file list" could have meant; I thought about a physical file containing the image list... but no: it was just the bare "list of files" as such. Maybe the label of this option could be better just "copy/paste" or "in situ". I will try that option next time. The errors you encountered were probably caused because the encoding via the browser is not UTF-8. You should have used wget on Linux, which works great. I have also a proper UTF-8 copy on a my laptop.

Here is the file: https://wikimedia.be/public/wlh/Montage_list_Wiki_Loves_Heritage_2021.txt

I encounter the same problem with a correct formatted file... problem is not solved...

@Mauricioadriano I proposed a workaround on 4 dec 2020, and at least 4 others confirmed that this solved their instance problem.

The problem seems to have disappeared. Pasting an Excel sheet with the Visual editor even works now with Firefox.

I am using standard versions of Excel and Chrome and Opera.

The problem has been solved, but please, can somebody document the root cause, and its solution? (and maybe indicate which hotline can be contacted in case the problem occurs again?).

I logged https://commons.wikimedia.org/wiki/Module_talk:Creator#Wikimedia_Commons_Module_creator_uses_a_wrong_regex_for_property_Property:P1053, but no response till now.

I have encountered a hanging script when my local network had a connectivity problem.

Why is this tool not proactively monitored?

It would be nice if someone could list here specific documentation how to implement a new data driven infobox on Wikipedia.

I get really confused now.

This is a known bug in the update script. The slots table was created in 1.31.10 (minor version). Normally there are only database changes in a major version. The update.php script should have automatically run the populateContentTables.php script during the upgrade, but it does not.

Thanks, problem solved, see https://be.wikimedia.org/wiki/Pywikibot/Mass_user_mailing/Send_email.py

Apparently the noratelimit right was removed from the group bots in Wikidata, see T258354 ?

Could it be acceptable to add e.g. ?

How could I request the noratelimit right?

I got a similar error halfway running update.php when upgrading from 1.31 to 1.35. It seems that the slots table was created in 1.31.10 (minor version) and that the populateContentTables.php script normally should have been executed automatically by the update.php script. Luckily by running the populateContentTables.php manually I could run update.php a 2nd time to execute the rest of the upgrade (without requiring to restore the database to the initial backup). Here is the log tail from the 1st run of update.php

Modifying table site_stats ...done.^M
Populating ar_rev_id.^M
Populating ar_rev_id...^M
MediaWiki\Revision\RevisionAccessException from line 1296 of /data/html/mediawiki-1.35.0/includes/Revision/RevisionStore.php: Main slot of revision not found in database. See T212428.^M

Sam, thanks for your help. Everything set now...

I am running a personal server on (a pre-release version of) MW 1.31 where indeed the . was not yet backslashed... so therefore I had to reverse the -. into .-

The remark about elif was only a slight CPU-friendly optimisation.
elif is indeed a Perl construct.
Could be coded instead as a nested else ... if with {}.