[Meta] Standardize capitalization on actions

Oh, yes please.

I remember being happy with things being lowercase in Drupal 4.7; now my tastes have changed, for some reason.

I do note some changes like this that may slightly be out of scope:

-    form_set_error('upload_uploadsize_default', t('The %role file size limit must be a number and greater than zero.', array('%role' => t('default'))));
+    form_set_error('upload_uploadsize_default', t('The <em>default</em> file size limit must be a number and greater than zero.'));

And, if we're changing that, IMO, it should be "The default file size limit must be a number greater than zero."

What lowercase things will this leave? "new", "updated", "published"? Is there a "promoted"?

Yeah, this has been one of my pet peeves with Drupal since forever.

Tagging.

And, +1.

I cannot review this without pictures, or something atleast.

This patch does not apply at all anymore.

I greped through some operations and found some missing the sentence casing:

• manage fields
• manage display
• remove items
• update items
• edit order and titles
• reset
• list links
• edit menu
• add link
• revert
• add translation
• edit role
• edit permissions
• locked

If we're just doing edit and delete in this round, however, I'd say this is RTBC.

Edit, Delete, View, Never and Configure is a good first round. RTBCed..... Should we open up issues to battle the ones I listed above? Or hit them after this patch is committed?

Before we commit this I think its very reasonable to actually look at the design part of this. Other then, I like it better this way - I would really love this late in the release cycle that we are a bit more cautious with just marking things RTBC.

One of the aesthetic reasons I felt was that in terms of typography it implies importance, where as the actions are not the most important part in the table its the information holder this being a node title, role title ect. With that in mind, it translates to the user as a consistent artifact in Drupal core - where all actions in a table are lowercase.

I am not totally set on this, but I would like to have actual arguments why it would be better. Translations is not a valid argument in my eyes, as that would mean a lot of our sentences in core which heavily rely on the span of the English vocabulary should be changed.

Can't really make the case for lowercase actions, though I do remember we made a conscious decision to use lowercase then. I think uppercase is fine. For operations in tables it will help just that little bit in seperating each action from the others:

edit operations edit permissions

Vs.

Edit operations Edit permissions

You know...

The more I think about this, as much as I would love to do this, since this drives me absolutely bananas as well, it's the kind of patch that is going to lead to all sorts of follow-ups, re-rolls of other peoples' patches, etc. This is exactly the kind of stuff we should've been focusing on *before* 12/1, and instead this new initiative is coming within the last two weeks of the first alpha. :\

The translator argument is compelling, but it wasn't compelling enough to block the release of Drupal 5 & 6, so I can't see how it could block the release of 7.x.

Therefore, I'm sorry to do this, but I'm going to have to bump to 8.x.

All good, no kittens lost :)

Coding standards fixes in core don't affect module developers. This does. They need to make changes to their UI strings to conform to core's standards which, for better or worse, have been consistent for the past 2 releases as lowercased. To be clear, it's not the act of having to re-roll patches that's problematic, it's the change in standard at this stage in the game.

It's also one of those patches where if there are any elements listed in #16 are missing, we must both postpone the time when we can tell translators to go ahead, and we add more things to the "must fix before release" queue, which is already at ~350 issues as it stands and we really don't need more of them. :(

Again, if this had been ready to go on 12/1, the deadline for major string/UI initiatives, things would've been different. The docs team was able to mount a huge initiative to change all help text in core by 12/1 to respect this deadline, for example. But I have to hold other patches to the same standard. Therefore, this feels pretty plainly like 8.x material to me. Restoring version.

I'm just frustrated that we don't have clear definitions about what our deadlines are allowing.

The 15th is the deadline for finalizing the clean-up patches from the previous phase that are already in the queue. It's not the time for starting new initiatives, particularly when said initiatives are non-critical, will result in dozens of follow-up patches, and make modifications that affect module developers.

I tried to clarify this here as well: http://webchick.net/node/73#comment-1312

In short, we've had over 3 months since feature freeze to perform clean-up work like this. The point of an alpha is to move us toward release, not further polishing. So if a patch isn't one of the ones that's been lingering at RTBC since December, or one that fixes critical bugs, let's address it in D8 imo.

Lets do this.

I'm OK with this patch but it doesn't quite apply anymore. Setting this back to 'Needs work'. Hopefully someone will be able to take a crack at this again. Thanks in advance.

Consensus on this being a good thing to do was there, is still there. I assume this is not complex but quite some grunt work and susceptible to rerolls? I'd love to see this move forward without becoming frustrating to do :)

Marked #364381: Capitalize strings wherever required as duplicate.

We should probably split the issue into maybe something like this to make it manageable:

• Node Operations table
• Watchdog
• Locale language operations
• Fields
• Aggregator feeds
• Blocks
• Book
• Comments
• Filter
• Image styles
• Taxonomy terms
• Menu links
• Shortcut
• User management and roles
• Actions UI
• Miscellaneous (IP blocking, date/time, etc)

Edit the summary

Edit summary

Edit summary

edit summary

Edit summary

Edit summary

Edit summary

Edit summary

Edit summary

Edit summary

add link

add link

add link

add link

add link

add link

edit summary

add link

add link

add link

add link

add links

Needs backport for #1496418: Views: Don't change capitalization of translatable strings with CSS and tons of other already fixed modules.

This is absolutely not backportable since it changes dozens of strings.

There are a lot of table 'operations' that use lower case like 'edit' and 'delete' but we don't use lowercase action words in buttons. I've heard from a couple of translators that these lowercase short action words are harder to translate. Many major contrib modules are also using propercase action words, like Organic Groups and Views.

As translator I can only confirm this. This needs a backport for translators.

Not sure what is going on with the tags.

Alright, while I understand the current behavior is frustrating for translators, D7 has been out for nearly 22 months. Most of these strings have already been translated to their lowercase versions despite the frustration. Backporting it now would instead cause sites upgrading to see all their short links and buttons in a foreign language, and that's way worse.

So we will fix it in D8. This is a safe task to do during D8 code freeze; it just needs to be completely done before string freeze.

text correction

Took a look at the previous patch and it seems like it's doing a lot of changes of edit -> Edit, delete -> Delete, view -> View, configure -> Configure and those are the kind of action word changes.

But it does not have changes to "short sentences", are there examples of how changes to use short sentences should be make, or should this just focus on the action words?

Linking issues using [#ISSUENUM] syntax

added example, and re-worded to be more clear.

typo

small typo

Updated issue summary.

Added:

• #1496418: Views: Don't change capitalization of translatable strings with CSS
• #1913958: Bartik theme: Don't change capitalization of translatable strings with CSS

changing title to take out the task of changing short sentences, because it's not clear what that is intended to do, and there is no example suggested yet.

In the separate issues,
what exactly should we be changing?

Just
t('edit') t('delete')
t('view'), t('never') and t('configure').

Plus, any word in the operations (drop buttons)?
Like #1784738: Standardize capitalization on actions, in content_types: 'manage fields', 'manage display', 'edit', 'delete' has t('manage fields')

Wait, I have another confusion. The issue summary says the separate issues are for the separate modules... but they kind of look like those sub issues are instead for the strings in the brackets. So, the separate issues were not created for the list in #34, but instead for the missing strings in #16

One problem, is that means, that the edit, delete, view, configure that there was wide agreement on, does not have a sub issue.

Even if we made sub issues for the list in #34, I dont think those are strickly modules, but maybe instead, areas in the UI, which multiple modules might contribute operations to. (I'm thinking translate is a node operation added by the content translation module.)

Suggestion

Lets get new issues opened up for the first two things in the list in #34 and start there.

ps. where is never an action word?

+++ modules/aggregator/aggregator.admin.inc	1 Jan 2010 18:32:25 -0000
@@ -27,7 +27,7 @@ function aggregator_view() {
+    $rows[] = array(l($feed->title, "aggregator/sources/$feed->fid"), format_plural($feed->items, '1 item', '@count items'), ($feed->checked ? t('@time ago', array('@time' => format_interval(REQUEST_TIME - $feed->checked))) : t('Never')), ($feed->checked && $feed->refresh ? t('%time left', array('%time' => format_interval($feed->checked + $feed->refresh - REQUEST_TIME))) : t('Never')), l(t('Edit'), "admin/config/services/aggregator/edit/feed/$feed->fid"), l(t('remove items'), "admin/config/services/aggregator/remove/$feed->fid"), l(t('update items'), "admin/config/services/aggregator/update/$feed->fid"));

aggregator...

+++ modules/user/user.admin.inc	1 Jan 2010 18:32:31 -0000
@@ -200,8 +200,8 @@ function user_admin_account() {
+      'access' =>  $account->access ? t('@time ago', array('@time' => format_interval(REQUEST_TIME - $account->access))) : t('Never'),

user admin

so yeah, we need screenshots. this is confusing.

We are changing to Delete, Edit, Manage fields and so on. There is nothing confusing in here.

Updated issue summary.

to reflect changes in issues needed.

Updated issue summary, sub issue information

Lets work on the various areas to get a feel for how to split this stuff up.
I tried to group things together already.
the issues really need screenshots.

For some to focus efforts on, lets try
#1785012: Standardize capitalization on actions for node operations: 'revert', 'view', 'edit', 'translate', 'delete'
#1784738: Standardize capitalization on actions, in content_types: 'manage fields', 'manage display', 'edit', 'delete'
and.. #1914220: Standardize capitalization in watchdog: 'debug', 'error', 'alert', etc.

Will we do changes to selects as part of the other open issues?
I think:
a) it would slow those issues down, and that changes to selects be separate issues, or
b) at least we get agreement here that changes to selects is A Good Thing.

I suggest a)

For example see:
#1785006-12: Standardize capitalization on actions for menu operations: 'add link', 'edit menu', 'delete menu', 'edit', 'delete', 'reset'
Changing menu name from <Administration> to - Administration -, alternate suggestion made to use brackets: [ ]
and
#1784806-11: Standardize capitalization on actions in book: 'edit order and titles'
which was missed when #1317884: Remove all instances of <none>, <Hidden> and <br/> from translatable strings because they lead to import errors happened.

As can be seen, there might need separate discussion and ui review on select changes.

Updated issue summary, added watchdog issue.

added separate issue to handle < and > found in select #1919258: Remove < and > from menu select for consistency

I feel like removing the word "actions" from title and make this case a full core review about single word/short sentences as noted in summary...

We should followup with larger patches now. Creating patches per module may take months for this trivial changes. E.g. Full modules folder in one patch, includes folder in one and so on.

adding follow-up issue

We need to decide if we do #1933082: Add context to short action names, too.

I think we need an issue to change the action words in the views ui.
See for example 9. the view in #1938576-1: Tags and Language setting not discoverable under "edit view name/description" button and #12
when the issue is created, add it to the issue summary and make a comment saying it was created and the summary was updated.

highlighting the remaining task.

Added link to #2004246 as sub-task

All of the tasks in the IS are fixed so closing this.