Change #1020880 had a related patch set uploaded (by Marco Fossati; author: Marco Fossati):

[mediawiki/extensions/UploadWizard@master] Upload Wizard Describe step: improve title, caption, and description

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

Submitted a draft patch that needs extra pairs of eyes. Moving to code review.

I think that we should first discuss the following ACs, CC @Sneha @AUgolnikova-WMF :

• Do not show any error message on load of the page. Error messages will only be shown when the user proceeds without entering required input.
• Pre-fill the title using file name if it matches the descriptive criteria, if not leave it blank

I'd love to hear the rationale behind these ones, as I'm inclined towards the opposite.

• Show a multi line description input box with the ability for the user to expand the input box using a corner handle. Keep the current functionality of it auto expanding as one needs more space.

The built-in corner handle also allows to expand horizontally, which breaks the UI. I suggest to keep the current behavior, instead.

@mfossati

• Do not show any error message on load of the page. Error messages will only be shown when the user proceeds without entering required input.

Rational for above AC: As best practice we should not show error message before the user has taken any action or has a chance to review what we are asking from them. Seeing error message as a default state when ones lands on a new page can be confusing.

• Pre-fill the title using file name if it matches the descriptive criteria, if not leave it blank

Rational for above AC: If the user's file name matches our title criteria it is good that we pre-fill it for the user. However, if the file name does not match our criteria it is best to leave it blank so that users can come up with a good title right at the start rather than them correcting it after we trigger an error message.

• Show a multi line description input box with the ability for the user to expand the input box using a corner handle. Keep the current functionality of it auto expanding as one needs more space.

For the above AC: If the corner handle breaks the UI then we can leave it out, especially if it is auto-expanding as one types, the corner handle feature may not be needed.

Back on it.

• Update the copy on the "view example" dialog as shown here

@Sneha, I think we need a Commons admin to update https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist-custom-filename. The patch has a temporary workaround so that we can test it, but I suggest to remove it before merging.
FYI the following custom messages also exist:

• https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist-custom-space
• https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist-custom-double-apostrophe
• https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist-custom-thumbnail
• https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist-custom-SVG-thumbnail

Everything else is done, moving to code review again.

@mfossati If I understood this correctly, it seem currently the dialog is pulling text from that first link and any changes on that page would be reflected in our dialog?

Could we have a custom dialog with only example text that is not linked to any of these pages. It seems there are a lot of variation of these pages so we can't confidently rely on one. We are not showing any links or additional text. We are only showing examples (which are unlikely to change.)

In T361049#9757575, @Sneha wrote:

@mfossati If I understood this correctly, it seem currently the dialog is pulling text from that first link and any changes on that page would be reflected in our dialog?

Correct. It's an on-wiki system message.

Could we have a custom dialog with only example text that is not linked to any of these pages. It seems there are a lot of variation of these pages so we can't confidently rely on one. We are not showing any links or additional text. We are only showing examples (which are unlikely to change.)

Yes, we could, but those messages seem to come from the community (e.g., https://commons.wikimedia.org/w/index.php?title=MediaWiki:Titleblacklist-custom-filename&action=history), so I'd opt for keeping the process intact, i.e., propose the updates on wiki. @Sannita, what do you think?

@Sneha , please also note that the other messages are actually triggered in other circumstances, e.g., something'' would trigger https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist-custom-double-apostrophe, so I suggest to review them.

@mfossati is it possible to see when these messages appear? Are their multiple error messages that show up? Because in my workflow I have only seen one that leads to this message.

@Sneha :

• spaces before a file extension should trigger https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist-custom-space, but I can't seem to hit that, e.g., pic .jpg still triggers https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist-custom-filename
• prefixes like 666px- trigger https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist-custom-thumbnail, e.g., 666px-pic
• prefixes like 666px- together with a .svg.png suffix trigger https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist-custom-SVG-thumbnail, e.g., 666px-pic.svg.png

We're asking the user to omit the file extension, so https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist-custom-space and https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist-custom-SVG-thumbnail are less likely.

In T361049#9759139, @mfossati wrote:

Yes, we could, but those messages seem to come from the community (e.g., https://commons.wikimedia.org/w/index.php?title=MediaWiki:Titleblacklist-custom-filename&action=history), so I'd opt for keeping the process intact, i.e., propose the updates on wiki. @Sannita, what do you think?

If it is needed to change system messages that are defined locally on Commons, we need to ask an interface administrator to intervene and change them. It's highly preferable to do this, instead of intervening ourselves without asking. Then, if we're in a hurry and/or nobody answers us in a week, we could go on our own, but I don't think this will be the case.

Those (and many more) messages are the result of an upload being rejected because the title violates the TitleBlacklist.
TitleBlacklist is a separate extension used to prevent spam and otherwise bad pages from being created on all wikis - it lets admins define patterns, and if a page name matches it, it'll be rejected.

That full list: https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist

AFAICT, that's these messages:

• titleblacklist-custom-hidden-char
• titleblacklist-custom-filename
• titleblacklist-custom-SVG-thumbnail
• titleblacklist-custom-thumbnail
• titleblacklist-custom-double-apostrophe
• titleblacklist-custom-space
• titleblacklist-custom-no-fileextension
• titleblacklist-custom-double-category-prefix
• titleblacklist-custom-editnotice
• Semiprotectedpagewarning
• Protectedpagetext/PageProtected
• Protectedpagetext

The vast majority of these seems to be "titleblacklist-custom-filename" - the one we're looking to alter.

FYI: many of the others will simply never be hit through UploadWizard (e.g. titleblacklist-custom-no-fileextension is irrelevant as UploadWizard will automatically add the extension, titleblacklist-custom-space won't trigger because UploadWizard automatically trims excess whitespace, and stuff like Protectedpagetext are irrelevant because UW doesn't submit in those namespaces)

We're limited in what we can do to change this, because this is not under our control. The community maintains this, and it is not limited to UploadWizard.

Options I can think of:

1. we duplicate the message(s) in UploadWizard and show our own version(s)
   • I would strongly advise against that because they could grow out of sync; if things end up being added/deleted/changed in the blacklist, the error message we'd be showing might be wrong
2. we show the original text, but trim the first and last paragraph
   • Again not a fan - if that format ever changes (and that is not under our control), or one of the languages these are translated in (e.g. https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist-custom-filename/nl) don't follow the same format, we may end up showing something broken
3. We propose certain changes to the community and hope that they agree and integrate them
   • Note: this may not work out, because this blacklist is not UploadWizard-specific; because it shows in many contexts (e.g. Special:Upload, article creation, ...), they may feel that the verbosity is needed
4. (variant on #1) if we really want to keep things simple and can't obtain it through #3, we could simply decide to not show that TitleBlacklist message at all, but some generic text (e.g. those examples) with a link to the TitleBlacklist message (so they are still able to learn exactly what rule they violated in case the examples didn't help)

Note: the temporary workaround Marco had in the code won't work in production (on-wiki messages override codebase messages)

Change #1020880 merged by jenkins-bot:

[mediawiki/extensions/UploadWizard@master] Upload Wizard Describe step: improve title, caption, and description

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

@Etonkovidova pinging for visibility

@Sneha - just double checking
(1) the scope of re-designing Describe step presently doesn't include Additional information from the figma mockup

(2) I have some problems testing these two AC:

• Pre-fill the title using file name if it matches the descriptive criteria, if not leave it blank
• Update the copy for the current error message for when the user has not entered a descriptive title as show here.

On commons beta the Title field is pre-filled with the automatically assigned unique name and there will be no warnings. In production, such pre-filled file name immediately triggers the user warning:

On commons beta I was not able trigger that warning. Although black-listed titles pages are present (e.g MediaWiki:Titleblacklist-custom-SVG-thumbnail), but the warning doesn't appear when I try to use black-listed titles. Two questions

• Is this a known deficiency of beta?
• the initial automatic title is considered to be descriptive enough?

In T361049#9784859, @Etonkovidova wrote:

(1) the scope of re-designing Describe step presently doesn't include Additional information from the figma mockup

Chiming in: this will be done in T361061: [M] Update the 'other information' field in upload wizard.

In T361049#9784859, @Etonkovidova wrote:

(2) I have some problems testing these two AC:

• Pre-fill the title using file name if it matches the descriptive criteria, if not leave it blank
• Update the copy for the current error message for when the user has not entered a descriptive title as show here.

There is no validation for a title to be actually descriptive - if I delete portion of that automatic title, the file name would be accepted.

I think that matches the descriptive criteria can be rephrased to validates against Titleblacklist rules: it's not really about being descriptive.

On commons beta I was not able trigger that warning. Although black-listed titles pages are present (e.g MediaWiki:Titleblacklist-custom-SVG-thumbnail),

These are Titleblacklist's custom system messages, which are different from the corresponding rules.

but the warning doesn't appear when I try to use black-listed titles. Two questions

• Is this a known deficiency of beta?

Yes, It seems so: there's no Titleblacklist rule on beta, see https://commons.wikimedia.beta.wmflabs.org/wiki/MediaWiki:Titleblacklist VS https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist.

@Etonkovidova

On commons beta the Title field is pre-filled with the automatically assigned unique name and there will be no warnings. In production, such pre-filled file name immediately triggers the user warning:

This is working as intended in commons beta. The error (if any) should appear when user hits next.

In T361049#9785334, @mfossati wrote:

In T361049#9784859, @Etonkovidova wrote:

(2) I have some problems testing these two AC:

• Pre-fill the title using file name if it matches the descriptive criteria, if not leave it blank
• Update the copy for the current error message for when the user has not entered a descriptive title as show here.

There is no validation for a title to be actually descriptive - if I delete portion of that automatic title, the file name would be accepted.

I think that matches the descriptive criteria can be rephrased to validates against Titleblacklist rules: it's not really about being descriptive.

On commons beta I was not able trigger that warning. Although black-listed titles pages are present (e.g MediaWiki:Titleblacklist-custom-SVG-thumbnail),

These are Titleblacklist's custom system messages, which are different from the corresponding rules.

but the warning doesn't appear when I try to use black-listed titles. Two questions

• Is this a known deficiency of beta?

Yes, It seems so: there's no Titleblacklist rule on beta, see https://commons.wikimedia.beta.wmflabs.org/wiki/MediaWiki:Titleblacklist VS https://commons.wikimedia.org/wiki/MediaWiki:Titleblacklist.

@mfossati for clarification! I'm trying to get this type of warning:

• I added a simple rule (disallow repeated letters as a file title) to commons beta MediaWiki:Titleblacklist
• the matching error message is on MediaWiki:Titleblacklist-custom-filename
• that message gets displayed when a user enters a file name matching the rule. The popup has an old design (the same as in current production).

What steps are needed for getting a new warning popup? Should be the message on commons beta MediaWiki:Titleblacklist-custom-filename changed?

In T361049#9787078, @Sneha wrote:

@Etonkovidova

On commons beta the Title field is pre-filled with the automatically assigned unique name and there will be no warnings. In production, such pre-filled file name immediately triggers the user warning:

This is working as intended in commons beta. The error (if any) should appear when user hits next.

@Sneha, @mfossati - the user warning about a title not being descriptive nevers appears in commons beta. There is an interesting double reload action in the field when the page loads, but no warning.

@Etonkovidova The copy in the old warning about needs to be revised by the community. @Sannita is going to reach out to community to create a new message with just examples. Until then we ware using the old message which is why I strikethrough one of the AC related to it.

@Etonkovidova for the recording you sent you above, do you get the error after you hit next? None of the errors should appear right away as they are in the video. Errors should only appear if the user tries to proceed without filling the form properly.

In T361049#9790936, @Sneha wrote:

@Etonkovidova The copy in the old warning about needs to be revised by the community. @Sannita is going to reach out to community to create a new message with just examples. Until then we ware using the old message which is why I strikethrough one of the AC related to it.

thx, @Sneha for clarification!

In T361049#9790942, @Sneha wrote:

@Etonkovidova for the recording you sent you above, do you get the error after you hit next? None of the errors should appear right away as they are in the video. Errors should only appear if the user tries to proceed without filling the form properly.

I double-checked: the error messages work as expected - they appear after a user click on the Publish files. Or, if a user hits the Back button and then returns to the Describe step. I think it's an acceptable error messages behavior. Or the error messages should appear only after clicking on the Publish files button?

@Etonkovidova The error messages should only appear after clicking on Publish. However, if one goes back after the errors were triggered, then those errors can stay on the page upon return. However, if errors were never triggered/shown then they should not appear even if one goes back one step and come back to the describe step.

However, my assumption is that users going back may not be a very common scenario and so if its not working as stated above we can consider it as a low priority issue.

@Etonkovidova I also noticed that the "description is required" error appears as soon as you uncheck the box that says "same as caption". In this case also the error should not appear until the user hits publish.

Also I think we should also file a bug for errors appearing after going back and coming to the describe page. Some appear and others don't so it is a bit inconsistent. If no errors were triggered before they should not appear.

@Sneha - thank you for the comments above. I filed T365067: UploadWizard - Describe step: message "Caption/Description is required" should appear only upon submitting - added those two cases to, i.e. the Back button case and unchecking "Same as caption" checkbox.