Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Search on drupal.org is disabled at the moment so I apologize if this is already discussed elsewhere. When using Google to search for similar issues, I found another person say "I wrongly assumed it was about 'Localization' because its path is 'locale'" so it seems I'm not the only one with the problem I'm about to describe.
I recently changed the time zone in the system settings for a site I manage and realized that it was unnecessarily difficult to inform my site members that they might need to update their own time zone settings. In my mind I started to picture countless support emails where my members were asking me where the "time zone settings" were in the account settings.
After 5 seconds, I did what I think anyone would do and changed the "Locale settings" string on the user edit page to "Time zone settings" (this particular site is in English, so this patch only affects the system.module and system.admin.inc files).
This should also be an unnecessarily step for Drupal administrators. I understand if the Locale settings fieldset was destined for more features and form widgets, but from what I can tell it only contains the time zone settings and should therefore be named "Time zone settings."
Steps to reproduce
The screenshots in #9 are still the same on Drupal 9.2.x.
Proposed resolution
Original proposal - Change the "Locale settings" string on the user edit page to "Time zone settings".
In #9 chris_h recommends
Change the "Locale settings" string on the user edit page to "Time zone settings".
On admin/config/regional/settings change Locale to Country
On admin/config/people/accounts/form-display change Timezone to Time zone
Remaining tasks
Decide is this should be done.
User interface changes
Yes. No screenshots yet.
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #21 | UserProfile-9.2.x.png | 27.37 KB | quietone |
| #9 | Screen Shot 2015-01-18 at 22.59.55.png | 87.95 KB | chris_h |
| #9 | Screen Shot 2015-01-18 at 22.59.45.png | 59.17 KB | chris_h |
| #9 | Screen Shot 2015-01-18 at 22.58.32.png | 19.87 KB | chris_h |
| #9 | Screen Shot 2015-01-18 at 22.51.25.png | 968.91 KB | chris_h |
Comments
Comment #1
stevenpatzComment #3
Tor Arne Thune commentedStill a valid issue after the release of 7.0. Moving to 8.x. See attached screenshot for how it is now on the user edit page.
Comment #4
albert volkman commentedUpdated for 8.x.
Comment #7
albert volkman commentedRe-roll
Comment #8
jhedstromPatch still applies, tagging for usability review.
Comment #9
chris_h commentedI've reviewed and this comes up in a few places
1) The installer, which uses default country/time zone
2) the user edit page, which uses Locale settings (can't set country)
3) admin/config/regional/settings which uses Locale/Time zones
4) admin/config/people/accounts/form-display which uses Timezone
For consistency we should amend to:
1) no change
2) change to Time zone as per patch
3) change Locale to Country
4) change Timezone to Time zone
Comment #10
mile23Wondering what has changed since #9...
2) User edit form still uses 'Locale.'
3) admin/config/regional/settings still uses Locale and Time Zones.
4) admin/config/people/accounts/form-display still uses Timezone.
Comment #19
pameeela commentedI am not so sure about this change, the fieldset label is 'Locale settings' and the field label is 'Timezone'. I don't really think it's adding much to update the fieldset to be 'Timezone settings' when the field label says this already.
Would it make more sense to remove the fieldset and just display the field within the form, as with the other user fields? (But then, do we need to do the same for 'Contact settings'? Or is there a reason it's in a fieldset?)
Comment #20
ramya balasubramanian commentedHi @pameela,
As per your previous comment, can we remove the fieldset and keep the fieldlabel alone in User edit page & Contact settings page. Please have a look and let me know what needs to be changed here.
Comment #21
quietone commentedI've read the issue, checked the current state of the pages on Drupal 9.2.x. and agree with #19, I am not sure about this change. And as she points out removing the fieldset for the time zone is inconsistent with the 'Contact settings'
It would be helpful to know how christefano communicated to users of the site that they might need to update their time zone settings.
Actually, after more thought on this maybe this is a won't fix. However, since this affect user facing text I am not comfortable changing the status to that. How about, Needs Review, to help reach a consensus.
Added a screen shot with the contact settings.
Comment #22
kristen polMy 2 cents after reading #9 and later:
1) The installer, which uses default country/time zone
Agree that no change is needed.
2) the user edit page, which uses Locale settings (can't set country)
Options: a) leave as is, b) change to Time zone as per patch, or c) remove fieldset
I think it's best to leave as is or remove the fieldset. But, the UX team should be consulted for the latter.
3) admin/config/regional/settings which uses Locale/Time zones
I disagree with changing the fieldset label from Locale to Country because "First day of week" has nothing to do with the country, so I would leave this as is.
If this were to be made more consistent with the previous item's Locale fieldset, then the time zone settings could be combined with the country and first day of the week. So, I'd say either leave as is or ask the UX team about combining the fieldsets.
4) admin/config/people/accounts/form-display which uses Timezone
I agree that it would be good to standardize on "timezone"/"timezones" or "time zone"/"time zones" throughout the UI to be consistent. Unfortunately, the codebase uses "timezone" as one word (e.g. "Timezone for DateTimePlus") in some places and "time zone" as two words in others (e.g. "'Correct time zone field"). We could still go through the UI and make sure the usage is either one word or two words if we want but there is a good chance that the "other" usage will crop into the UI again since the codebase uses both.
At this point, I would say it would be good to consult with the UX team on their thoughts since these aren't obvious.
Comment #23
quietone commentedI discovered a related issue, which has suggests a different change to the user edit page. I rerolled it to make an up to date screenshot.
Comment #24
jibranThis seems like a task now rather than a bug. Also, closing this as a duplicate of #134209: Join language and timezone settings in one single fieldset as consolidation of the fields under one fieldset and renaming it makes sense than removing the fieldset altogether.