⚓ T361049 [XL] Improve the file name, caption, and description fields
Page Menu
Phabricator
Create Task
Maniphest
T361049
[XL] Improve the file name, caption, and description fields
Closed, Resolved
Public
Actions
Edit Task
Edit Related Tasks...
Create Subtask
Edit Parent Tasks
Edit Subtasks
Merge Duplicates In
Close As Duplicate
Edit Related Objects...
Edit Commits
Edit Mocks
Mute Notifications
Protect as security issue
Assigned To
mfossati
Authored By
Sneha
Mar 26 2024, 7:30 PM
2024-03-26 19:30:32 (UTC+0)
Tags
UploadWizard
(Backlog)
Structured-Data-Backlog (Current Work)
(Needs QA)
MW-1.43-notes (1.43.0-wmf.5; 2024-05-14)
Referenced Files
F52003859: flashing_commons.mov
May 11 2024, 12:54 AM
2024-05-11 00:54:58 (UTC+0)
F51997523: Screen Shot 2024-05-10 at 5.19.31 PM.png
May 11 2024, 12:40 AM
2024-05-11 00:40:19 (UTC+0)
F51997561: Screen Shot 2024-05-10 at 5.19.17 PM.png
May 11 2024, 12:40 AM
2024-05-11 00:40:19 (UTC+0)
F51996108: Screen Shot 2024-05-09 at 3.47.55 PM.png
May 11 2024, 12:40 AM
2024-05-11 00:40:19 (UTC+0)
F51560293: Screen Shot 2024-05-09 at 3.54.18 PM.png
May 9 2024, 11:22 PM
2024-05-09 23:22:10 (UTC+0)
F51559993: Screen Shot 2024-05-09 at 4.01.10 PM.png
May 9 2024, 11:22 PM
2024-05-09 23:22:10 (UTC+0)
F51552289: Screen Shot 2024-05-09 at 3.24.47 PM.png
May 9 2024, 11:22 PM
2024-05-09 23:22:10 (UTC+0)
F51552163: Screen Shot 2024-05-09 at 3.24.56 PM.png
May 9 2024, 11:22 PM
2024-05-09 23:22:10 (UTC+0)
Subscribers
Aklapper
AUgolnikova-WMF
Etonkovidova
matthiasmullie
Sannita
Sneha
Description
This task is part of improving the describe step of the Upload Wizard on Commons
T358765
. Refer to overall design discovery and design goals in this ticket
T358614
In order to simplify the information that users need to fill out describe step, the following changes to the UI are proposed
Visual improvements:
Improve the overall layout by following new styling and spacing for the form and its fields
Copy improvements:
Changing headers and helper text for each of the field
Required field:
Making caption a required field
Changes to description field:
Adding an option for users to copy their caption to description
Title
Link to UI
Update the label for the title field from image title to title
Remove the label description from the title field
Show a single line input box
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.
Update the copy for the current error message for when the title is not unique as show
here
If the user proceeds without a title show the error as shown
here
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
Update the copy on the "view example" dialog as shown
here
(pending community review see discussion below)
Caption
Link to UI
Make the caption field a required field. Remove the optional label
Update the label description to the following copy: "One-line explanation"
Have the language selector take the full width of the input box
Remove the delete icon for the first caption
Show the delete icon for all the subsequent language captions that users adds as shown
here
Show a single line caption input box
If the user proceeds without entering a caption show an error message as shown
here
Description
Link to UI
Description remains a required field
Update the label description to the following copy: "We recommend providing detailed information on this work if you can"
Automatically copy caption to description by default unless the "same as caption" box is unchecked
Hide the description input box and show "same as caption" checkbox selected by default as shown
here
When the "same as caption" checkbox is unselected, reveal the description blank input box as shown
here
Remove the delete icon for the first caption
Show the delete icon for all the subsequent language descriptions that users adds as shown
here
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.
If the user proceeds without entering a description show an error message as shown
here
Details
Related Changes in Gerrit:
Subject
Repo
Branch
Lines +/-
Upload Wizard Describe step: improve title, caption, and description
mediawiki/extensions/UploadWizard
master
+205
-41
Customize query in gerrit
Related Objects
Search...
Task Graph
Mentions
Status
Subtype
Assigned
Task
Open
None
T358765
[EPIC] Describe step UX improvements in the UW on Commons
Resolved
mfossati
T361049
[XL] Improve the file name, caption, and description fields
Mentioned In
T391249: Evaluate if "captions" changes on the describe page on UW is resulting in more "captions" statements
T286852: In the "Describe" tab, UW prompts for "Image title" when uploading a PDF.
T330546: "This field is required" in Uploader form is ambiguous
T364794: [beta] UploadWizard - Describe step: the warning about a title not being descriptive enough should be present
T364593: [QA task] UploadWizard - testing Describe step
T358765: [EPIC] Describe step UX improvements in the UW on Commons
Mentioned Here
T364794: [beta] UploadWizard - Describe step: the warning about a title not being descriptive enough should be present
T365067: UploadWizard - Describe step: message "Caption/Description is required" should appear only upon submitting
T361061: [M] Update the 'other information' field in upload wizard
T358614: UX design for improving describe step in upload wizard
T358765: [EPIC] Describe step UX improvements in the UW on Commons
Event Timeline
Sneha
created this task.
Mar 26 2024, 7:30 PM
2024-03-26 19:30:32 (UTC+0)
Restricted Application
added a subscriber:
Aklapper
View Herald Transcript
Mar 26 2024, 7:30 PM
2024-03-26 19:30:44 (UTC+0)
Sneha
added a parent task:
T358765: [EPIC] Describe step UX improvements in the UW on Commons
Mar 26 2024, 7:31 PM
2024-03-26 19:31:39 (UTC+0)
Sneha
renamed this task from
Redesign the describe step in the upload wizard
to
Improve the file name, caption, and description fields
Mar 26 2024, 8:11 PM
2024-03-26 20:11:20 (UTC+0)
Sneha
updated the task description.
(Show Details)
AUgolnikova-WMF
mentioned this in
T358765: [EPIC] Describe step UX improvements in the UW on Commons
Mar 27 2024, 2:42 PM
2024-03-27 14:42:36 (UTC+0)
MarkTraceur
edited projects, added
Structured-Data-Backlog (Current Work)
; removed
Structured-Data-Backlog
Apr 1 2024, 6:52 PM
2024-04-01 18:52:03 (UTC+0)
MarkTraceur
moved this task from
Incoming
to
Needs Design
on the
Structured-Data-Backlog (Current Work)
board.
Apr 1 2024, 6:54 PM
2024-04-01 18:54:36 (UTC+0)
Sneha
updated the task description.
(Show Details)
Apr 2 2024, 8:08 PM
2024-04-02 20:08:57 (UTC+0)
Sneha
moved this task from
Needs Design
to
Ready for Estimation
on the
Structured-Data-Backlog (Current Work)
board.
Sneha
updated the task description.
(Show Details)
Apr 3 2024, 7:13 PM
2024-04-03 19:13:47 (UTC+0)
MarkTraceur
renamed this task from
Improve the file name, caption, and description fields
to
[XL] Improve the file name, caption, and description fields
Apr 4 2024, 8:53 PM
2024-04-04 20:53:09 (UTC+0)
MarkTraceur
moved this task from
Ready for Estimation
to
Ready for Development
on the
Structured-Data-Backlog (Current Work)
board.
mfossati
changed the task status from
Open
to
In Progress
Apr 9 2024, 10:41 AM
2024-04-09 10:41:14 (UTC+0)
mfossati
claimed this task.
mfossati
moved this task from
Ready for Development
to
Doing
on the
Structured-Data-Backlog (Current Work)
board.
gerritbot
added a comment.
Apr 17 2024, 5:58 PM
2024-04-17 17:58:36 (UTC+0)
Comment Actions
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
gerritbot
added a project:
Patch-For-Review
Apr 17 2024, 5:58 PM
2024-04-17 17:58:36 (UTC+0)
mfossati
moved this task from
Doing
to
Code Review
on the
Structured-Data-Backlog (Current Work)
board.
Apr 17 2024, 6:14 PM
2024-04-17 18:14:48 (UTC+0)
mfossati
added a subscriber:
AUgolnikova-WMF
Comment Actions
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.
Sneha
added a comment.
Apr 23 2024, 5:33 PM
2024-04-23 17:33:16 (UTC+0)
Comment Actions
@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.
Sneha
updated the task description.
(Show Details)
Apr 24 2024, 4:03 PM
2024-04-24 16:03:43 (UTC+0)
mfossati
moved this task from
Code Review
to
Doing
on the
Structured-Data-Backlog (Current Work)
board.
Apr 26 2024, 3:13 PM
2024-04-26 15:13:19 (UTC+0)
Comment Actions
Back on it.
mfossati
moved this task from
Doing
to
Code Review
on the
Structured-Data-Backlog (Current Work)
board.
Apr 30 2024, 9:19 AM
2024-04-30 09:19:43 (UTC+0)
Comment Actions
Update the copy on the "view example" dialog as shown
here
@Sneha
, I think we need a Commons admin to update
. 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:
Everything else is done, moving to code review again.
Sneha
added a comment.
Apr 30 2024, 12:46 PM
2024-04-30 12:46:49 (UTC+0)
Comment Actions
@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.)
mfossati
added a subscriber:
Sannita
Apr 30 2024, 6:45 PM
2024-04-30 18:45:32 (UTC+0)
Comment Actions
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.,
), 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
, so I suggest to review them.
Sneha
added a comment.
Apr 30 2024, 7:49 PM
2024-04-30 19:49:02 (UTC+0)
Comment Actions
@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.
mfossati
added a comment.
May 1 2024, 9:26 AM
2024-05-01 09:26:16 (UTC+0)
Comment Actions
@Sneha
spaces before a file extension should trigger
, but I can't seem to hit that, e.g.,
pic .jpg
still triggers
prefixes like
666px-
trigger
, e.g.,
666px-pic
prefixes like
666px-
together with a
.svg.png
suffix trigger
, e.g.,
666px-pic.svg.png
We're asking the user to omit the file extension, so
and
are less likely.
Sannita
added a comment.
May 1 2024, 9:46 AM
2024-05-01 09:46:28 (UTC+0)
Comment Actions
In
T361049#9759139
@mfossati
wrote:
Yes, we could, but those messages seem to come from the community (e.g.,
), 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.
matthiasmullie
subscribed.
Edited
May 3 2024, 11:57 AM
2024-05-03 11:57:51 (UTC+0)
Comment Actions
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:
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:
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
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.
) don't follow the same format, we may end up showing something broken
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
(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)
gerritbot
added a comment.
May 7 2024, 3:49 PM
2024-05-07 15:49:27 (UTC+0)
Comment Actions
Change #1020880
merged
by jenkins-bot:
[mediawiki/extensions/UploadWizard@master] Upload Wizard Describe step: improve title, caption, and description
ReleaseTaggerBot
added a project:
MW-1.43-notes (1.43.0-wmf.5; 2024-05-14)
May 7 2024, 4:00 PM
2024-05-07 16:00:52 (UTC+0)
Maintenance_bot
removed a project:
Patch-For-Review
May 7 2024, 4:30 PM
2024-05-07 16:30:54 (UTC+0)
mfossati
moved this task from
Code Review
to
Needs QA
on the
Structured-Data-Backlog (Current Work)
board.
May 8 2024, 8:32 AM
2024-05-08 08:32:19 (UTC+0)
AUgolnikova-WMF
added a subscriber:
Etonkovidova
May 9 2024, 10:53 AM
2024-05-09 10:53:52 (UTC+0)
Comment Actions
@Etonkovidova
pinging for visibility
Sneha
updated the task description.
(Show Details)
May 9 2024, 12:41 PM
2024-05-09 12:41:05 (UTC+0)
Etonkovidova
updated the task description.
(Show Details)
May 9 2024, 10:18 PM
2024-05-09 22:18:39 (UTC+0)
Etonkovidova
added a comment.
Edited
May 9 2024, 11:22 PM
2024-05-09 23:22:10 (UTC+0)
Comment Actions
@Sneha
- just double checking
(1) the scope of re-designing
Describe
step presently doesn't include
Additional informatio
n 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:
If in production I change that file name to some other common name, I'll see the warning again:
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.
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?
Etonkovidova
mentioned this in
T364593: [QA task] UploadWizard - testing Describe step
May 9 2024, 11:43 PM
2024-05-09 23:43:08 (UTC+0)
Etonkovidova
updated the task description.
(Show Details)
May 10 2024, 12:06 AM
2024-05-10 00:06:55 (UTC+0)
Etonkovidova
updated the task description.
(Show Details)
May 10 2024, 2:33 AM
2024-05-10 02:33:35 (UTC+0)
Etonkovidova
updated the task description.
(Show Details)
May 10 2024, 2:37 AM
2024-05-10 02:37:56 (UTC+0)
mfossati
added a comment.
May 10 2024, 8:12 AM
2024-05-10 08:12:21 (UTC+0)
Comment Actions
In
T361049#9784859
@Etonkovidova
wrote:
(1) the scope of re-designing
Describe
step presently doesn't include
Additional informatio
n from the figma mockup
Chiming in: this will be done in
T361061: [M] Update the 'other information' field in upload wizard
mfossati
added a comment.
May 10 2024, 8:45 AM
2024-05-10 08:45:17 (UTC+0)
Comment Actions
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
VS
Sneha
added a comment.
Edited
May 10 2024, 8:10 PM
2024-05-10 20:10:19 (UTC+0)
Comment Actions
@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.
Etonkovidova
added a comment.
May 11 2024, 12:40 AM
2024-05-11 00:40:19 (UTC+0)
Comment Actions
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
VS
@mfossati
for clarification! I'm trying to get this type of warning:
What I did:
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?
Etonkovidova
added a comment.
Edited
May 11 2024, 12:54 AM
2024-05-11 00:54:58 (UTC+0)
Comment Actions
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.
flashing_commons.mov
2 MB
Sneha
added a comment.
May 13 2024, 3:52 PM
2024-05-13 15:52:17 (UTC+0)
Comment Actions
@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.
Sneha
added a comment.
Edited
May 13 2024, 3:54 PM
2024-05-13 15:54:31 (UTC+0)
Comment Actions
@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.
Etonkovidova
added a comment.
May 13 2024, 9:56 PM
2024-05-13 21:56:12 (UTC+0)
Comment Actions
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
mentioned this in
T364794: [beta] UploadWizard - Describe step: the warning about a title not being descriptive enough should be present
May 13 2024, 10:17 PM
2024-05-13 22:17:52 (UTC+0)
Sneha
added a comment.
May 14 2024, 8:14 PM
2024-05-14 20:14:36 (UTC+0)
Comment Actions
@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.
Sneha
added a comment.
Edited
May 15 2024, 8:38 PM
2024-05-15 20:38:26 (UTC+0)
Comment Actions
@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.
Etonkovidova
added a comment.
May 15 2024, 9:10 PM
2024-05-15 21:10:37 (UTC+0)
Comment Actions
@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.
Etonkovidova
updated the task description.
(Show Details)
May 16 2024, 12:04 AM
2024-05-16 00:04:17 (UTC+0)
Etonkovidova
closed this task as
Resolved
May 16 2024, 12:07 AM
2024-05-16 00:07:56 (UTC+0)
Comment Actions
Re-checked on
commons wmf. 5
- seems to be working according to the specs
The following AC work on
commons wmf.5
(which makes
T364794
only
commons beta
issue)
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.
The current behavior in
commons wmf..5
Upload step
: a file is assigned an automatically generated name
Describe step
: the automatically generated title is not displayed - no warning or user message to provide descriptive title
Some non-descriptive titles will trigger "Please write a more informative title (see examples)" message. The examples of such titles -
TTTT
Image123
, and
test12321321 454
simon04
mentioned this in
T330546: "This field is required" in Uploader form is ambiguous
Jun 4 2024, 8:59 PM
2024-06-04 20:59:38 (UTC+0)
simon04
mentioned this in
T286852: In the "Describe" tab, UW prompts for "Image title" when uploading a PDF.
Jun 23 2024, 5:40 PM
2024-06-23 17:40:09 (UTC+0)
AUgolnikova-WMF
mentioned this in
T391249: Evaluate if "captions" changes on the describe page on UW is resulting in more "captions" statements
Apr 7 2025, 11:52 AM
2025-04-07 11:52:28 (UTC+0)
Log In to Comment
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct.
Wikimedia Foundation
Code of Conduct
Disclaimer
CC-BY-SA
GPL
Credits
US