Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.This didn't start to really stick out to me until I recently had to start writing out pain-staking instructions for configuring Drupal sites.
Most places under the administration panel, the instructions are:
"Do some blah blah thing and click Save configuration."
Others (for example, Taxonomy), it's:
"Click Add Vocabulary, and enter the following settings, and click Save:"
Then in other places still (user profiles, node add page), it's Save again.
So how about we standardize on all forms using "Save" instead of variations like "Save configuration."
| Comment | File | Size | Author |
|---|---|---|---|
| #29 | 199430.patch | 37.75 KB | robloach |
| #24 | save-vs-savefoo.patch | 56.12 KB | keith.smith |
| #12 | save_save-2.patch | 16.23 KB | keith.smith |
| #11 | save_save.patch | 16.25 KB | keith.smith |
| #8 | 199430_1.patch | 1.07 KB | keith.smith |
Comments
Comment #1
patchnewbie commentedThis would be a good patch for someone new to Drupal dev.
Comment #2
Stefan Nagtegaal commentedI would prefer to have page dependant submit buttons strings like we have 'Save blocks'. (Which isn't the best either, but okay).
"Save blocks" => 'Save block configuration'
'Save' (on taxonomy page) => 'Save taxonomy' (Or some better description!)
etc, etc
Comment #3
webchickBut I already know I'm on the blocks page. What else would I be saving?
Furthermore, there's no clean way to do this for nodes, and have it look consistent with capitalization etc. of other pages. Let's go for simple, no? :)
Comment #4
catchMassive, massive +1 for standarising on Save. I noticed this when doing #195678 but thought they were all "save configuration" on purpose. Another issue is when you're used to seeing "Save" but actually see something else - you can start wondering where the "Save" button went - might only be for a fraction of a second but it's enough to make things less smooth.
Comment #5
robloachSubscribing and sticking my vote in for "Save". You're already on a configuration screen, so you already know you're going to be saving the configuration. It would also help bring some standardization with the contrib modules' update from "Submit" to "Save".
Comment #6
keith.smith commentedCompletely untested patch changing the instances of "Save configuration" I found during a grep of core into "Save"
Comment #7
webchickI grepped for "'Save " and found a bunch more:
Comment #8
keith.smith commentedHrm. Yes, apparently I didn't imagine the full...er....range...of values that could follow "Save " on a submit button.
Turns out I missed, well, most of them.
But, this creates another question: on /admin/content/types/page, for instance, we have "Save content type" and "Delete content type". If we modify the "Save content type" to "Save", would not "Delete content type" (and friends) need to transition to simply "Delete"? What about "Reset to defaults"? Should this be simply "Reset"? It's easy enough to change these too, but I thought I'd pose the question before I did it.
Also, this issue was spawned [I think] from comments on the inconsistencies in the installer submit buttons. Indeed, those buttons used both "Save configuration" and "Save". I had initially (in the patch in #6) modified these to simply "Save". I interpret webchick's commented text in #7 to suggest that [at least the first two of] these perhaps should be "Next". I ran through the installer this way, though, and it felt strange to me -- with a "Next" button, I expect there to be a "Previous" or "Back" button, I think.
The attached patch changes the three occurrences in install.php to "Save and continue" (and does not address "Save *" buttons anywhere else). I ran through the installer again, and this seemed pretty natural -- even the last button named this seems ok since you still "continue" to the final installer page.
Any feedback on this and whether "Delete *" buttons should also be modified to just Delete is greatly appreciated.
Comment #9
webchickI'd +1 that change. However...
I would say no. "Reset" doesn't give enough context about what that button will actually do. "Reset to defaults" doesn't really, either, but "Remove all variables from the variable table that affect this settings page so that the default values are used" is too long. ;P So it's fine for now I think. Unless we maybe want "Reset to default values"?
"Save" vs. "Delete" on the other hand, are very clear about what they're talking about, since they're on the form itself, so I support shorter names there.
Yeah, that's true. This came up because one of the GHOP students mentioned that the wording here was all over the place during the installation section. Sometimes it was Next, sometimes it was Save configuration, etc. and pointed out that we should standardize on something that means "Go to the next step in the installer." It's scope creep for this issue, so feel free to leave it as just "Save" for now.
Comment #10
keith.smith commentedI've moved the patch in #8 dealing with installer buttons only to the issue it actually belonged in, http://drupal.org/node/199402.
Comment #11
keith.smith commentedOK. The attached path modifies "Save foo" buttons so that they simply say "Save", and "Delete foo" buttons so that they say "Delete".
I grepped pretty extensively through stuff, and hope that I got them all, along with references to them in help text and the like.
We need to give this a good test since it has the potential to break, well, a lot of stuff.
No installer buttons have been renamed in the making of this patch. (They have their own issue at http://drupal.org/node/199402.)
Comment #12
keith.smith commentedBit of fuzz, so rerolling.
Comment #13
gábor hojtsyWhile I am sympathetic with the goals of this patch, I am not sure whether there was some kind of usability reason behind longer text on buttons, so they are easier to click. Anyway, more review/feedback would be good.
Comment #14
webchickI can't speak to that myself, but I do know that arguably the most common form that all users will submit (the create content form) was changed to "Save" earlier this cycle. So my feeling is that those longer buttons are probably legacy things.
Comment #15
Nick Lewis commented+1 for "Save".
Reasons:
-More text != usability. It should be clear to the user what any button labeled "save" will save without providing an extra noun, and descriptive text.
-The language is the same as most desktop applications.
-It's a simple rule; therefore, it will encourage consistent language throughout the drupal UI.
Comment #16
gábor hojtsyAs explained earlier, this needs a bit more thought. We cannot change all "Save ..." to "Save" without considering other UI elements around the buttons. (Heh, until a minute ago we even had one remaining button titled 'Submit').
Comment #17
panchoWhile this is not our common approach, I think in this case we really could rename all "Save x" buttons to "Save" for now, and wait to see if this creates any UI problems in one or the other case. We now have a general rule, and for an exception to that rule, there has to be strong evidence that the rule doesn't make sense in that case.
Comment #18
webchickRC1 is out. No more string changes. Bumping to 7.x.
Comment #19
birdmanx35 commentedOkay, there is a bit of fuzz when applied to core, but overall this still applies cleanly to HEAD.
Comment #20
gddPatch now failing in
comment.module
content_types.inc
system.module
user.admin.inc
Rest applies with offset and/or fuzz. Needs a reroll.
Comment #21
keith.smith commentedI'll re-roll this soon.
Comment #22
SeanBannister commentedWaiting to test a reroll
Comment #23
keith.smith commentedYes, I'll reroll. I completely lost this patch off my radar.
Comment #24
keith.smith commentedAt long last, here's a new patch to rename buttons to simply "Save".
Gabor's comments in #16 are well taken; if this is committed, we need follow-up patches to rename "Delete foo" buttons to "Delete, and, possibly "Reset to defaults" to simply "Reset".
I had a few tests fail, but they also fail without the patch. Let's see what the testing bot says.
Comment #26
robloachI just tested this patch locally and tests are running, and it looks good in my eyes... Submitting for re-test.
Comment #28
robloachUhh, I think the testing suite needs to update Drupal HEAD.
Comment #29
robloachThe thing I like about "Save $foo" is that it gives it some context, so if you want to override it using something like String Overrides, you can.
In any case, here's an updated patch that only hits "Save configuration".
Comment #31
catchWe have context for t() now. I don't think context is actually supplied in many places, but it ought to be possible to do tell which form you're on or similar assuming everything's done right. #334283: Add msgctxt-type context to t()
Comment #32
plachAfter reading #927792-13: Please explain what is still considered for D7 I guess this is for D8 now.
Comment #33
catchAgreed.
Comment #34
jhedstromComment #35
robloach"Save".... Will see about rerolling this patch.
Comment #36
mgiffordUnassigning stale issue. Hopefully someone else will pursue this.
Comment #50
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #51
catchThis is still valid. Sometimes we have just 'Save', sometimes 'Save block' or 'Save layout' or 'Save settings' or 'Save configuration'. The vast majority are 'Save' so I think we should standardise on that.
No such thing as 'string freeze' any more so updating the issue title.