See https://www.mediawiki.org/wiki/User:MarkTraceur/UploadWizard/Book_uploads/Initial_thoughts - this is already in our plan for fixing bug 47561.

Also https://gerrit.wikimedia.org/r/66561 is the work in progress patch.

What is the current status of this? I see there is activity on the Gerrit patchset ; is there anything where we could help?

(In reply to Jean-Fred from comment #3)

What is the current status of this? I see there is activity on the Gerrit
patchset ; is there anything where we could help?

It's iffy.

Template support basically rests on the assumption that we'll be using templates long-term to do metadata storage - which is a bad assumption, though we don't yet know *how* bad.

I'll initiate a conversation on Multimedia-l about Wikidata on Commons once I see the appropriate signals go through where they need to; currently I don't think everyone's in the loop about this, and we definitely haven't made any decisions.

(In reply to Mark Holmquist from comment #4)

I'll initiate a conversation on Multimedia-l about Wikidata on Commons once
I see the appropriate signals go through where they need to; currently I
don't think everyone's in the loop about this, and we definitely haven't
made any decisions.

Has that happened? If so, archive link welcome.

This project is picking up some speed and all information is being tracked from: https://www.mediawiki.org/wiki/Multimedia/Structured_Data

I think it is safe to assume that adding Artwork support is currently looking unlikely, favoring investing in structured data support for Commons.

The patch needs some cleanup, including migration to JSON l10n format. https://gerrit.wikimedia.org/r/66561

However, are we really going to hardcode even more Commons templates into the UploadWizard extension itself? Wouldn't it be vastly better to allow such data/mapping to be maintained on-wiki, perhaps in a MediaWiki page as the Campaigns extension does or in a special page or in collaboration with the TemplateData extension?

Change 66561 had a related patch set uploaded (by Nemo bis):
Will allow dynamic form generation in the details step

https://gerrit.wikimedia.org/r/66561

Change 66561 abandoned by Bartosz Dziewoński:
Will allow dynamic form generation in the details step

Reason:
I don't think this can be rescued, sorry :(

https://gerrit.wikimedia.org/r/66561

In T51443#1492162, @MarkTraceur wrote:

I think this is going to be obviated soon, with the emergence of more specialized upload tools for specialized cases like artwork. We should be able to do it more easily outside of UploadWizard.

Really not intending to be snarky, but: 2 years later, where are those "more specialized upload tools for specialized cases"? If they exist, none of them seems to be listed at Commons:Upload tools.

This issue will not go away with Structured Commons, just to be clear on that. To help understand this issue, here is a mapping from the artwork template to Wikidata using an example from a 17th-century painting: https://commons.wikimedia.org/wiki/File:Commons_vs_Wikidata_for_PD-Art-100-1923_images.png

added to https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey/Wikidata#Integrate_Pattypan_and_Quick_Statements

@Jane023 true, BUT it's easier to write tools that work and scale, when you are working with a predictable structure. If I can code: "Add widget that lists P186 to upload form", instead of having to deal with wiki text and arbitrarily configured json files, then short term, that's easier and long term, its more maintainable.

But in the end, if you make things complicated, then it's not easy to "uncomplicated" them with some UI sprinkles, that is true.

In T51443#3762028, @TheDJ wrote:

@Jane023 true, BUT it's easier to write tools that work and scale, when you are working with a predictable structure.

What is unpredictable about the image that I linked above? I noticed that the recent proposer in the 2017 wishlist also wants it for paintings. I like paintings and apparently so do a lot of other people, considering how many we have on Wikidata and how many we have yet to do that are currently locked in information templates on Commons.

@Jane023 the picture isn't unpredictable. The wiki text and the interpretation of that wiki text is (That's exactly what structured data is all about....).

So yes, if the argument is "I want this", then there are no blockers for making another few exceptions and flows in the UI. But if we want to design products with a purpose and want them to fit in with a strategic direction, then we are spending time where it won't have return of investment in the long term and we might need to reimplement later on. However, I see no evidence of anyone willing to invest in either, so i'd say there is little point in discussing potential implementation solutions.

Ah I believe you are confusing the two issues - future software implementations and current backlog cleanup drives paired with reducing future backlog. Implementation of this will at least allow people to correct the stuff they upload (or have already uploaded with the default uploader).

yeah i understand if you have never tried to clean the metadata mess at commons, you would not see the point to the task.
the workaround currently is to use pattypan and not use upload wizard.
it takes some expertise to know not to use the tool, that does not support linking to wikidata.

@Slowking4 I was one of the three people who created all template logic for our metadata. It was my idea to do the whole metadata cleanup drive. I maintained UW for a few years. I was invited to the initial meetings where we discussed the ideas of structured commons and then decided that we shouldn't do it for a few more years... I think i know what i'm talking about.

i think it is great that you know enough to file a "will not fix"
i guess i will stop making what little metadata cleanup i was doing by hand,
steering newbies to a cul-de-sac that creates more backlog is not isolated to this process.
i'm sure you will have a solution for this metadata debt in you own time.

and i added this to the wishlist yet again this year, if you would care to respond. https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey/Multimedia_and_Commons

This is no about me. It's about keeping things separate.
1: fulfill short term goal
2: fulfill long term goals.

This ticket was originally picked up and discussed with a long term viewpoint in mind by the multimediateam. As such the Structured data ideas were related to this. After 2014 this ticket was derailed because due to multimediaviewer we suddenly didn't have a multimedia team any longer, causing any investment in Commons to die with it. If the community wishes to get this fixed through the wishlist, then that turns this ticket in the realization of a short term goal. But then you can dismiss anything that was written about this ticket between when it was opened and november of this year, because most of that had to do with realizing longterm goals.

As such I felt I had to explain to @Jane023 that bringing structure data into this discussion is irrelevant Long term goals and short term fixes rarely go hand in hand.

[edit] lemme rephrase that. @Jane023's original comment led me to believe she figured that structured data was not relevant to the solution strategy discussed in this ticket. I disagreed with that and tried to explain that the previous mentions of structured data had a logical origin and had fundamental technical benefits for the long run.

Then it turns out that people are bringing this up in the context of the survey; The survey is about short term investment, and that would certainly be possible here. it is my conviction however that a short term solution here is a waste of investment and only creates further burden,, as since we are now all in on Commons data again (long term), we would need to reimplement this later on.

Filed https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey/Multimedia_and_Commons/Improve_UploadWizard_campaigns . Shouldn't be too hard to do and would add the flexibility to upload other templates without cluttering up the main work flow.

here is some metadata cleanup that could have been avoided had this been implemented sooner

https://commons.wikimedia.org/w/index.php?title=File%3ADe_Tuinier_Jenny_Montigny.jpg&type=revision&diff=271131089&oldid=257149785

and

https://commons.wikimedia.org/w/index.php?title=File%3AFeria_campesina.jpg&type=revision&diff=271131740&oldid=222024606