For this first version I would suggest two paths:

• index.html, a simple static website with a form. (Technically, probably a Jinja2 template served by Flask, but I’m not sure if we’ll use any templating features.) The form POSTs to massmessage.
• massmessage, which upon POST runs the script and returns its output (MassMessage syntax) as text/plain. For any other request types (e. g. GET) it probably redirects back to index.html.

WDYT? (I’m not yet sure about the massmessage path… could be anything, really.)

A rudimentary first version of this is available under https://tools.wmflabs.org/wdmm/wikidata-massmessage?id=Q6811431. Source code lives in ~tools.wdmm/www/python/src/, and it’s already a Git repository, but I haven’t pushed it anywhere yet (I couldn’t figure out how to create a Diffusion repository for it – see T190835), so for now only other people with shell access to the tool can see it.

Okay, the tool has a proper index page now, plus loads more features. Please take a look at https://tools.wmflabs.org/wdmm/! (pinging @Lea_Lacroix_WMDE)

Still no Diffusion or GitHub repository, but I symlinked the source code into tools-static as a temporary hack (link is in the navbar – opening it in the browser isn’t very useful, but you can git clone it).

Thanks @Lucas_Werkmeister_WMDE for this first prototype! Two things I'd like your opinion on:

1. I think there are two different stories about selecting items.

• the "fallback" case: I want the technical village pumps OR, if it doesn't exist on the wiki, the regular village pump
• the "addition" case: I want a list with the Lua project pages AND the Wikidata project pages

One could even imagine a combination of these two: I want to write on the Lua project page and the Wikidata project page but if none of these exist on the wiki, then take the regular village pump

Do you think there is a way to do this? And to represent the different cases in a clear way on the interface?

Note that "wow it's too complex let's do it later or never" is an acceptable answer :)

If we keep the fallback-only case for now, I'd like to have several fields where only one item can be entered, I think that would be clearer.
Item ID: [---Field1---]
Fallback (optional): [---Field2---]
Second fallback (optional): [---Field3---]
I think 3 fields are enough for most of the use cases.

2. For the wikigroups, instead of a list with only one option, can we have a checkbox list? Maybe I want all the projects BUT Wikivoyage and Wikisource for some reason. Ideally all the boxes would be ticked by default when loading the page.

Thanks again for your work!

Hm, for the combinations I could think of something textual like Q123+(Q456,Q789) but I guess that’s not very usable :)

If we limit it to a fixed number of fields, I guess it should still be possible, with something like:

Write to:      [item ID 1] falling back to [item ID 2] falling back to [item ID 3]
also write to: [item ID 4] falling back to [item ID 5] falling back to [item ID 6]
also write to: [item ID 7] falling back to [item ID 8] falling back to [item ID 9]

Regarding multiple wikigroups, if you think that’s useful I could add it (not sure if I prefer checkboxes or a <select multiple>… I guess checkboxes would be better). And in that case options for the single-wiki groups (commons, mediawiki, meta, species, wikidata) should also be added.

By the way, we now have a proper Diffusion repository for this tool: https://phabricator.wikimedia.org/source/tool-wdmm/

Support for more than one wikigroup now available. I went for a <select multiple> after all, since I couldn’t figure out a good way to style a long list of checkboxes… is that okay?

About the “use talk page” checkbox – if we support combinations of target pages, how many times does that checkbox need to be there? Do we need one checkbox per “write to…” row, applying to all the fallbacks as well? Or does this need to be configurable per fallback? I feel like the former case is more likely.

Thanks for the select multiple! Looks good to me.

Let's try with 3 possible combinations, each having 2 possible fallbacks. I think that covers most of our usecases.
And I'm afraid that the "use talk page" checkbox is needed for each field. For example if I write to Project:Lua pages with fallback Village pumps, for the first I need to write on the talk page, for the second it's the main page ^^"

I guess that checking for duplicates at the end before rendering the list will be also useful :)

And I'm afraid that the "use talk page" checkbox is needed for each field. For example if I write to Project:Lua pages with fallback Village pumps, for the first I need to write on the talk page, for the second it's the main page ^^"

Yeah, I realized the same thing later. I think I have the HTML side working – how does this look?

Now I need to prepare the backend for this…

Looks very good, thanks!
I'll prepare a short introduction text to add under the title of the tool.

Great, thanks! That should make the tool much easier to understand :)

I’ve pushed some work in progress to the repository, but not deployed it to Toolforge yet. I’ll probably continue working on this after the long weekend.

I did flake8 fixes in https://phabricator.wikimedia.org/R2307:91f39748c3dcfbc97b06a13f10f75df5c31d47cf

I also reviewed the code and it looks pretty nice except the runScript() function that would be great if you can split it into smaller functions.

Great, thanks! We can probably get rid of most of runScript() once the port to Python is done (I’ll continue working on this today).

Okay, the Python rewrite is done, no more shell script :)

@Lea_Lacroix_WMDE can you take a look at the new UI? If you’re okay with it (and after we’ve added the short introduction text), I think we could close this task, and do any further improvements in T190795: Add tool to write MassMessage to all pages linked to a Wikidata item or new subtasks of it instead.