Date range should be in the date_time category

I've added 📌 Refine field descriptions Active as a related issue. I wonder if the entire point 2 from the proposed resolution could be done in the scope of the linked issue which is about refining the microcopy. That way the copy would be consistent when it is done in a single issue there?

@rkoller I agree that refining microcopy would be best done on a dedicated issue.

Created MR to address point 1.

Added screenshot for review.

Thanks for creating the MR with the initial change, we'll need the rest before the review can start.

I've wrapped the category into @Translation. The description is already added for the field, see screenshot so do we have to add it anywhere else?
The description for the category is already updated at https://www.drupal.org/project/drupal/issues/3372097 📌 Consider replacing hook_field_type_category_info with YML based plugin discovery Fixed

@anushrikumari, you added
category = @Translation("Date and Time")
Just category machine name is needed. (its "date_time" inside datetime)
category = "date_time",
Its still showing inside a separate group

I have updated the category machine name & patch added, please review.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

It should be category = "date_time" you can compare it to the other date widgets.

Please leave "Needs work" until someone sets out the text in the same way to the other date widgets.

Added the description similar to the date field. Also updated the category to "date_time". Attached screenshot for the description.

Thank you. I think this will need something that describes why a site builder would use this field instead of simply using two date fields.

Updated description that defines the module functionality. I would like some suggestions about the info that we should add/keep or omit from below -

• Users can specify a start date and an end date for the content, defining the duration of the event or period.
• With the date range field, users can easily search and filter content based on specific date criteria.
• Field options
  • Date and Time: Stores date and time component.(E.g Thu, 11/02/2023 - 09:00 - Thu, 11/16/2023 - 17:00)
  • Date - Stores date only and time is set 12:00 hrs as default. (E.g Thu, 11/02/2023 - 12:00 - Thu, 11/16/2023 - 12:00)
  • All Day - Stores date and time, starting with 00:00 hrs of start date and 23:59 hrs of end date (Thu, 11/02/2023 - 00:00 - Thu, 11/16/2023 - 23:59)
• Basic validation that date range provides
• If the one date has value then other date cannot be NULL.
• The end date is always greater than start date.

Seems to have test failures in MR.

Thank you @anushri19 this is good progress. I've screenshot the current version below for UX team review and added the tag.

I've looked at the gitlab test output and I can't work out what might be failing due to this patch, i'm not sure what I'm missing something. I have rebased for good measure.

Proposed a simplified text in the MR. 😊

@ajaypratapsingh Thank you for working on this! This issue has a MR so it would be great if you could make the updates there 😊

Rebased the MR and updated the description as suggested in #22, thanks!

Tested MR-5397 and the changes have been updated perfectly. Attached screenshot for reference.
Thanks

Hi @lauriii
Some of my thoughts -
There is a full stop after the sentence in recent changes but with other field types there is no full stop in the description sentences so I think we need to add a full stop on the other field descriptions too for better experience. After the sentence is complete, there should be a full stop which is common.

https://www.stylemanual.gov.au/grammar-punctuation-and-conventions/punct....

Maybe we could remove the full stops here and open another issue to decide if we should use full stop across all field type descriptions.

I also added a proposal to remove the field options since that isn't something we have for other field types, and it makes the description very lengthy.

Removed full stops and field options from the description as suggested in #30
Thanks

Tagging for follow up per #30, hiding patches for clarity.

We already have a follow-up for refining the descriptions: 📌 Refine field descriptions Active . I added the full stop for bullet points as a consideration there.

This seems like a small enough issue to not require full on usability testing. Removing the tag and moving to RTBC since it would be nice to get this done before 10.2.0.

Committed/pushed to 11.x and cherry-picked to 10.2.x, thanks!

Automatically closed - issue fixed for 2 weeks with no activity.