Same as T247875#6053514: this could be done as an OAuth-powered Toolforge tool, which could serve both as a prototype for the future JSON editing UX in MediaWiki, and as a practical interim solution for editing (importing, reviewing etc) COVID-19-related data. The same tool could even serve for both tasks, as from a UX point of view wikitables and JSON data pages represent very similar data.

Because of that, the main shortcoming of JSON pages is IMO not the UX but the lack of support for granular (row or cell level) sourcing. Filed T250919: Add row/cell annotations to tabular data about that.

@Tgr are there any good templates/examples of setting up a toolforge tool? Something that would show all the basic building blocks (creating a "site", setting up oauth, connecting to a specific wiki, etc), so that a volunteer could just write the task-specific javascript?

Thx for the annotations issue link -- at this point one would have to add sources directly into the table as a column(s).

In T248897#6078632, @Yurik wrote:

@Tgr are there any good templates/examples of setting up a toolforge tool? Something that would show all the basic building blocks (creating a "site", setting up oauth, connecting to a specific wiki, etc), so that a volunteer could just write the task-specific javascript?

There are howtos for some languages/frameworks. I don't think there's one for pure client-side Javascript ATM - that requires OAuth 2, and support for that is fairly new. In any case, #wikimedia-cloud would be the best place to inquire.

We could do something along the lines of the TemplateData editor, which opens up a dialog from the normal edit page with input fields that are easier to interpret.

There is already a table editor in the Graph extension which allows the data of a graph to be edited as a table in visual editor. The metadata is edited via separate fields. It uses a table widget that could be upstreamed.

Here's a patch that hacks something like this together: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/JsonConfig/+/592695/

That makes use of the JsonConfig tabular format to find the data and column headings, so wouldn't work for editing just any JSON. But something like that could be useful for .tab pages.

@Tchanders this looks awesome!!! My understanding is that for MVP it should just allow editing of the existing tables, not change the table structure, right? Also, the multi-lingual column might be somewhat difficult to represent visually - how do you think it should be done? Thanks again!

Thanks @Yurik - yes, I'd approach this iteratively and start with only the data tables: T251759: Create a basic editing dialog for editing JSON tabular data as a table.

Here are some thoughts on editing the metadata - I agree the localized strings will be the most complicated:

Perhaps we could have something like a select with a text input for the localized strings?

Again we can approach this iteratively. Perhaps the first iteration could allow editing data for existing fields but not adding or removing them. Similarly the localized strings could just be added in a multiline text area to begin with.

Closing the dialog will just populate the editing textbox on the original edit page, so that will still handle validation.

Good details, thx. For the localized strings (both in the data and in metadata), I think the better way would be to have just a single "global" language selector somewhere at the top of the dialog, set to the user's language by default. Changing its value would only change what is being shown, but it won't do any data modifications.

A localized string could either have default white background (means the value has been entered in the current language), or a gray background (no value is set for the current language). If there are values in other languages but not in current, some value can still be shown in italic, together with the language code. Clicking on the field would start the process of adding a value in the current language. Deleting it would turn the field gray again.

On mouse over, localized field can show a tooltip with values in all or first 20(?) languages.

I think the editing interface should have a similar header as the data table's html page -- show 3 header rows instead of one. This way we can have proper place to show and edit column titles, descriptions, and types.

P.S. there should be some warnings to prevent accidents:

• when changing column name, warn that any modules or graphs using this data would need to be adjusted to use new column name.
• ???

I've created a Google SpreadsheetApp that takes in the json and makes the data array editable.
see T252336

T63989 implemented an editing interface for PageForms using jsGrid, which seems suitable for editing the data inside tabular data inline, if not the structure too.

Edit: Oh, didn’t see T251759 was already underway. Even better!

@1Veertje Thank you -- I find your tool also useful for working in the other direction: taking an existing spreadsheet and generating a tab file.

@Tchanders it may make sense to start with just editing the existing table, but just as important is the ability to add a new element/row with the same structure. Depending on the use case, edits to a given tab file tend to be bimodal: either (editing existing cells) or (adding a new row, never editing existing cells).

@1Veertje @mxn Thanks!

@Sj Thanks for that perspective - it's helpful to know how these pages are edited. Once T251759 lands it will be possible to edit the data, but adding/removing rows should follow soon. There are just some upstream bugs in the table UI that need fixing first. I expect metadata editing to be a bit more complicated - how much do you think that gets edited?

Metadata editing: it depends on the source. I could imagine people leaving many comments on a talk page, and someone familiar w/ how to update the metadata doing so periodically (once a week?) It's not something that every visitor needs to be able to easily do.

Removing "Product Doing" after 3 years.
@Tchanders: Are you still working on this?