[policy] Consistently use "email" instead of "e-mail" in Drupal

we can make "e-mail" consistent throughout the complete interface.

IMO we don't do this kind of polish anymore, that was for December 2009's freeze.

It's a good idea though to standardize on something.

http://en.wikipedia.org/wiki/Email#Spelling suggests 'email' is the way to go: AP Stylebook and Yahoo style guide are cited as resources there.

email +1

The content style guide for drupal.org states that we should use "e-mail" over "email" or "mail". The attached patch does just that.

I have refreshed the patch wmostrey posted to work with the current version of the 8.x branch. I followed Randy Fay's excellent walk through on doing so, http://randyfay.com/content/refreshing-stale-patch-git.

Attempt #3. It looks like prior to my patch creation I improperly committed a difference between the branches due to the staleness of the patch.

I just tested theMusician's patch and it worked great with the current version of D8.
For anyone else that wants to review the patch (and you're new to review patches like I am) here were my steps:

1. View an example of the incorrect usage of the word 'email' on the config page (/admin/config) under Development >> Logging and errors settings: '... database, email, etc.'
2. If you're in a LAMP-like environment like MAMP: Open terminal and stat, check and apply the patch;
   

   curl https://drupal.org/files/consistent_email_03.patch | git apply --stat
   curl https://drupal.org/files/consistent_email_03.patch | git apply --check
   curl https://drupal.org/files/consistent_email_03.patch | git apply
   

3. Clear caches
4. Review text on Configuration >> Development >> Logging: '... database, e-mail, etc.'

I applied the patch to the latest dev code and it applied cleanly.

Nice work everyone.

"e-mail" is definitely correct, yeah.

+++ b/core/modules/user/user.module
@@ -355,6 +355,219 @@ function user_load_by_name($name) {
+function user_save($account, $edit = array()) {

Invalid re-addition of already removed code. Make sure your HEAD is up to date.

Updated HEAD as of this morning. Refreshed the original patch again. Applied cleanly, after manually cleaning up a bunch of merge conflicts, to fresh pull of 8.x HEAD.

Doh! I missed a merge marker.

Wow, this has been a difficult day. I followed this nice writeup, to figure out what assertRaw() does.

It looks at the raw output of the HTML, and since the patch changes that output earlier, it caused the 1 failure in the test suite.

3rd time is the charm. (I hope :) )

Test the patch.

Since #16 turned green, I did a bit more of a nit-picky review of this patch. Here is what I noticed if this patch gets re-rolled again. Otherwise this patch looks good.

+++ b/core/includes/install.core.incundefined
@@ -1610,7 +1610,7 @@ function install_configure_form($form, &$form_state, &$install_state) {
-  // Add JS to show / hide the 'Email administrator about site updates' elements
+  // Add JS to show / hide the 'E-mail administrator about site updates' elements
   drupal_add_js('jQuery(function () { Drupal.hideEmailAdministratorCheckbox() });', 'inline');

This new comment exceeds 80 characters. Maybe change to 'show/hide'?

+++ b/core/modules/system/system.moduleundefined
@@ -3511,7 +3511,7 @@ function system_action_info() {
+ * Return a form definition so the Send e-mail action can be configured.

Should be 'Returns' instead of 'Return'.

+++ b/core/modules/user/user.admin.incundefined
@@ -428,7 +428,7 @@ function user_admin_settings($form, &$form_state) {
+  // These e-mail tokens are shared for all settings, so just define
   // the list once to help ensure they stay in sync.
   $email_token_help = t('Available variables are: [site:name], [site:url], [user:name], [user:mail], [site:login-url], [site:url-brief], [user:edit-url], [user:one-time-login-url], [user:cancel-url].');

This comment should be rewrapped to better fit in 80 characters.

+++ b/core/modules/user/user.moduleundefined
@@ -2127,7 +2127,7 @@ function _user_mail_text($key, $langcode = NULL, $variables = array()) {
  * _user_mail_text() to set up some additional tokens that can be
- * used in email messages generated by user_mail().
+ * used in e-mail messages generated by user_mail().

This comment also should be rewrapped.

Thanks @Lars Toomre. I used your suggestions to update the comment wrapping. However, for the last one you mentioned in user.module I didn't see a way to enhance the wrapping so I left that one as is.

Please let me know if there are other issues with the patch.

Hrm, looks like I'm too late. The additional changes suggested in #18 are scope-creep, since none of them is caused by this patch.

Please only change "email" to "e-mail" in this patch, nothing else.

No reason to undo the few additional changes now. But in general, it is highly recommended to verify and ensure that the scope of an issue and change proposal is and remains focused and limited.

This looks RTBC to me, but I'll let someone else review and confirm.

@sun re: #21 - In the documentation clean-up patches, we were urged to fix other documentation problems on the exact lines of documentation we were touching. Hence, I do not think that the changes in #18 were scope creep.

I have reviewed once again all of the changes in this patch and all are appropriate. I did not check if any other stings of 'email' remain in core. However, I trust that others have. RBTC for the changes in #19.

I also tested the patch and and confirm that it works.
You can quickly verify the change on these pages:
/admin/config
'email' found under 'Development' > 'Logging and errors'
/admin/help/openid
'email' found under: 'Uses' > 'Logging in with OpenID'
/admin/help/search
'email' found under 'Uses' > 'Searching content and users'

I did a search through the latest codebase and found 47 other instances of ' email' (white-space included).
I've broken them out into types: Interface Text (14), Comments (29) and XML (4). Only a few files have both interface text and comments that may need to be updated: WebTestBase.php, EmailTest.php, UserRegistrationTest.php.

I would suppose that a patch fixing the 14 'Interface Text' files and comments therein is in order.
The question I have it whether it's best to create a follow up patch to theMusician's or a new patch that encompasses all the changes.

Any feedback on other files to include is welcome as well.

Interface Text

1. String: $this->assertEqual($user->mail, 'john@example.com', t('User was registered with right email address.'));
   filename="d8:core:modules:openid:lib:Drupal:openid:Tests:OpenIDRegistrationTest.php"
   rangemin="2630" rangemax="2636"
2. String: $this->assertEqual($user->mail, 'john@example.com', t('User was registered with right email address.'));
   filename="d8:core:modules:openid:lib:Drupal:openid:Tests:OpenIDRegistrationTest.php"
   rangemin="4736" rangemax="4742"
3. String: $this->assertEqual($user->mail, 'john@example.com', t('User was registered with right email address.'));
   filename="d8:core:modules:openid:lib:Drupal:openid:Tests:OpenIDRegistrationTest.php"
   rangemin="12394" rangemax="12400"
4. String: $this->assertEquals('example@example.com', $bag->filter('email', '', false, FILTER_VALIDATE_EMAIL), '->filter() gets a value of parameter as email');
   filename="d8:core:vendor:symfony:http-foundation:Symfony:Component:HttpFoundation:Tests:ParameterBagTest.php"
   rangemin="6374" rangemax="6380"
5. String: ...$duplicate_user->mail)), t('Supplying a duplicate email address with added whitespace displays an error...
   filename="d8:core:modules:user:lib:Drupal:user:Tests:UserRegistrationTest.php"
   rangemin="6442" rangemax="6448"
6. String: ...&lt;a href="@url">%name</a> was created without an email address, so no welcome message was sent.',...
   filename="d8:core:modules:user:lib:Drupal:user:RegisterFormController.php"
   rangemin="4555" rangemax="4561"
7. String: ...t('Expected text found in @field of email message: "@expected".', array('@field' =>...
   filename="d8:core:modules:simpletest:lib:Drupal:simpletest:WebTestBase.php"
   rangemin="99424" rangemax="99430"
8. String: ...t('Expected text found in @field of email message: "@expected".', array('@field' =>...
   filename="d8:core:modules:simpletest:lib:Drupal:simpletest:WebTestBase.php"
   rangemin="98756" rangemax="98762"
9. String: ...t('Supplying an exact duplicate email address displays an error message'));
   filename="d8:core:modules:user:lib:Drupal:user:Tests:UserRegistrationTest.php"
   rangemin="6038" rangemax="6044"
10. String: 'description' => 'Testing that only user with the right permission can see the email address in the user search.',
    filename="d8:core:modules:user:lib:Drupal:user:Tests:UserSearchTest.php"
    rangemin="487" rangemax="493"
11. String: 'description' => 'Tests the form API email element.',
    filename="d8:core:modules:system:lib:Drupal:system:Tests:Form:EmailTest.php"
    rangemin="493" rangemax="499"
12. String: 'description' => 'The {language}.langcode that the user prefers for receiving emails and viewing the site.',
    filename="d8:core:modules:user:user.install"
    rangemin="6412" rangemax="6418"
13. String: 'description' => 'The {language}.langcode that the user prefers for receiving emails and viewing the site.',
    filename="d8:core:modules:user:user.install"
    rangemin="10926" rangemax="10932"
14. String: 'name' => 'Form API email',
    filename="d8:core:modules:system:lib:Drupal:system:Tests:Form:EmailTest.php"
    rangemin="442" rangemax="448"

Comments

1. String: // Attempt to bypass duplicate email registration validation by adding spaces.
   filename="d8:core:modules:user:lib:Drupal:user:Tests:UserRegistrationTest.php"
   rangemin="6118" rangemax="6124"
2. String: // attributes like name and email (*sigh*). We ask for both axschema.org
   filename="d8:core:modules:openid:openid.module"
   rangemin="33384" rangemax="33390"
3. String: // Default display includes name and email address; if too long, the email
   filename="d8:core:modules:dblog:lib:Drupal:dblog:Tests:DBLogTest.php"
   rangemin="8370" rangemax="8376"
4. String: // Default display includes name and email address; if too long, the email
   filename="d8:core:modules:dblog:lib:Drupal:dblog:Tests:DBLogTest.php"
   rangemin="8338" rangemax="8344"
5. String: // Ensure that there is no textfield for email.
   filename="d8:core:modules:contact:lib:Drupal:contact:Tests:ContactAuthenticatedUserTest.php"
   rangemin="1059" rangemax="1065"
6. String: // Hide the additional settings when the blocked email is disabled.
   filename="d8:core:modules:user:user.admin.inc"
   rangemin="22325" rangemax="22331"
7. String: // Hide the additional settings when this email is disabled.
   filename="d8:core:modules:user:user.admin.inc"
   rangemin="21002" rangemax="21008"
8. String: // If configured time between notifications elapsed, send email about
   filename="d8:core:modules:update:update.module"
   rangemin="12696" rangemax="12702"
9. String: // If email verification is off, hide the password field and just fill
   filename="d8:core:modules:openid:openid.module"
   rangemin="9705" rangemax="9711"
10. String: // If the OpenID provider did not provide both a user name and an email
    filename="d8:core:modules:openid:openid.module"
    rangemin="29910" rangemax="29916"
11. String: // Send emails after we have the new user object.
    filename="d8:core:modules:user:lib:Drupal:user:UserStorageController.php"
    rangemin="7439" rangemax="7445"
12. String: // The user's status is changing; conditionally send notification email.
    filename="d8:core:modules:user:lib:Drupal:user:UserStorageController.php"
    rangemin="7613" rangemax="7619"
13. String: // Try to hijack the email field with a valid email.
    filename="d8:core:modules:system:tests:modules:form_test:form_test.module"
    rangemin="53408" rangemax="53414"
14. String: // Try to hijack the email field with a valid email.
    filename="d8:core:modules:system:tests:modules:form_test:form_test.module"
    rangemin="53433" rangemax="53439"
15. String: // Use the email returned by Simple Registration if available.
    filename="d8:core:modules:openid:openid.module"
    rangemin="9256" rangemax="9262"

Multiline Comments

1. String: * denominator of Internet email, with lines of no more than 998 characters."
   filename="d8:core:modules:system:lib:Drupal:system:Tests:Mail:HtmlToTextTest.php"
   rangemin="14939" rangemax="14945"
2. String: * Email messages sent using functions other than drupal_mail() will not
   filename="d8:core:modules:system:system.api.php"
   rangemin="61757" rangemax="61763"
3. String: * Number of emails to search for string, starting with most recent.
   filename="d8:core:modules:simpletest:lib:Drupal:simpletest:WebTestBase.php"
   rangemin="97892" rangemax="97898"
4. String: * obtain it through the world-wide-web, please send an email
   filename="d8:core:vendor:doctrine:common:tests:NativePhpunitTask.php"
   rangemin="287" rangemax="293"
5. String: * Optional number of emails to output.
   filename="d8:core:modules:simpletest:lib:Drupal:simpletest:WebTestBase.php"
   rangemin="99632" rangemax="99638"
6. String: * original author names and emails are not known
   filename="d8:core:vendor:doctrine:common:lib:Doctrine:Common:Util:Inflector.php"
   rangemin="1330" rangemax="1336"
7. String: * Outputs to verbose the most recent $count emails sent.
   filename="d8:core:modules:simpletest:lib:Drupal:simpletest:WebTestBase.php"
   rangemin="99569" rangemax="99575"
8. String: * Returns HTML for an email form element.
   filename="d8:core:includes:form.inc"
   rangemin="167742" rangemax="167748"
9. String: * SMS, Email, pager, syslog, ...etc.
   filename="d8:core:modules:system:system.api.php"
   rangemin="79577" rangemax="79583"
10. String: * Tests email element.
    filename="d8:core:modules:system:lib:Drupal:system:Tests:Form:EmailTest.php"
    rangemin="163" rangemax="169"
11. String: * Tests that name and email fields are not present for authenticated users.
    filename="d8:core:modules:contact:lib:Drupal:contact:Tests:ContactAuthenticatedUserTest.php"
    rangemin="630" rangemax="636"
12. String: * The email address used for initial account creation.
    filename="d8:core:modules:user:lib:Drupal:user:User.php"
    rangemin="2027" rangemax="2033"
13. String: * The user's email address.
    filename="d8:core:modules:user:lib:Drupal:user:User.php"
    rangemin="517" rangemax="523"
14. String: * The user's preferred langcode for receiving emails and viewing the site.
    filename="d8:core:modules:user:lib:Drupal:user:User.php"
    rangemin="1635" rangemax="1641"

XML

1. String: <lead user="beberlei" name="Benjamin Eberlei" email="kontakt@beberlei.de"
   filename="d8:core:vendor:doctrine:common:build.xml"
   rangemin="1937" rangemax="1943"
2. String: <lead user="guilhermeblanco" name="Guilherme Blanco" email="guilhermeblanco@gmail.com"
   filename="d8:core:vendor:doctrine:common:build.xml"
   rangemin="1756" rangemax="1762"
3. String: <lead user="jwage" name="Jonathan H. Wage" email="jonwage@gmail.com"
   filename="d8:core:vendor:doctrine:common:build.xml"
   rangemin="1663" rangemax="1669"
4. String: <lead user="romanb" name="Roman Borschel" email="roman@code-factory.org"
   filename="d8:core:vendor:doctrine:common:build.xml"
   rangemin="1846" rangemax="1852"

Tossing this one to Jennifer.

Well... hmm. E-mail is not a countable noun (mail isn't, so e-mail isn't), so the text should never say "e-mails". It should say either "e-mail" or "e-mail messages". For instance here:

+ * For example: When configuring automated e-mails, an administrator enters
...
+    $message['body'][] = t('Your site is currently configured to send these e-mails when any updates are available. To get notified only for security updates, !url.', array('!url' => $settings_url));
   }
   else {
+    $message['body'][] = t('Your site is currently configured to send these e-mails only when security updates are available. To get notified for any available updates, !url.', array('!url' => $settings_url));

But I guess this can be fixed in a follow-up or a different issue.

And this change:

-    $message['body'][] = "--\nMail sent out from " . config('system.site')->get('name');
+    $message['body'][] = "--\nE-mail sent out from " . config('system.site')->get('name');

This changes mail to e-mail -- why?

I'm uncertain as to whether that should be committed, so I'm setting this patch back to needs review for the moment.

Thanks for the discussion of this everyone and _vid for pointing out there had been many additions since the original patch created by wmostrey.

I recreated the patch with the additions found by Vid where I thought they made good sense. I did not update the string in core/modules/update/config/update.settings.yml as I am not familiar with the yaml language. It looks like it is setting an array.

I updated emails to e-mail messages as well. Thanks Jennifer. Regarding your last comment Mail is changed to E-mail to keep it consistent.

#27: consistent_email_950534_08.patch queued for re-testing.

I figured the patch would probably no longer apply :(

It would have been nice if it did apply. I am guessing that there are now more variations of e-mail or just more instances of it throughout. I will see if I can set aside some time to search for e-mail and make the patch once again.

It's probably just that things that patch is trying to change have since been affected by new commits, so it doesn't apply cleanly.

IIRC there are tags to notify maintainers that a quick commit of this patch would be appreciated, before it rots again. Not sure what they are though offhand, though they may well be of use here! :)

Thanks for the tip joachim. I'll look for the tag. Is there still value in the patch? I like consistency, but do others find it needed for core?

DrupalCon Portland code sprint: attempting reroll

So.... The real question we should address before we make a patch here is:

Is our style guide being stupid to advocate "e-mail" instead of "email"? I just wonder what is considered standard in the writing industry these days. Can we do a bit of research (AP style guide, etc.) and see if we should update our standard? That choice of "e-mail" was made many many years ago.

To @jhodgdon - I think that it should be one way or the other. In this patch I have flipped everything to 'e-mail' - I can re-do this patch and flip everything back the other way should the community decide to go with 'email' - no problem!

I decided to start from scratch on this patch. This is a site-wide inventory on the strings I found suitable for replacement as of May 24 2013.

Files touched

1. core/includes/install.core.inc
2. core/includes/mail.inc
3. core/lib/Drupal/Core/TypedData/Type/Email.php
4. core/lib/Drupal/Core/Utility/Token.php
5. core/misc/ui/README.md
6. core/modules/action/action.module
7. core/modules/comment/comment.tokens.inc
8. core/modules/contact/lib/Drupal/contact/Tests/ContactAuthenticatedUserTest.php
9. core/modules/dblog/lib/Drupal/dblog/Tests/DbLogTest.php
10. core/modules/openid/lib/Drupal/openid/Tests/OpenIDRegistrationTest.php
11. core/modules/openid/openid.module
12. core/modules/search/search.module
13. core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.php
14. core/modules/system/lib/Drupal/system/Tests/Mail/HtmlToTextTest.php
15. core/modules/system/system.api.php
16. core/modules/system/system.tokens.inc
17. core/modules/update/update.module
18. core/modules/user/lib/Drupal/user/AccountSettingsForm.php
19. core/modules/user/lib/Drupal/user/Plugin/Core/Entity/User.php
20. core/modules/user/lib/Drupal/user/Plugin/views/field/Mail.php
21. core/modules/user/lib/Drupal/user/RegisterFormController.php
22. core/modules/user/lib/Drupal/user/Tests/UserAdminTest.php
23. core/modules/user/lib/Drupal/user/Tests/UserCreateFailMailTest.php
24. core/modules/user/lib/Drupal/user/Tests/UserPasswordResetTest.php
25. core/modules/user/lib/Drupal/user/Tests/UserRegistrationTest.php
26. core/modules/user/lib/Drupal/user/Tests/UserValidationTest.php
27. core/modules/user/lib/Drupal/user/UserStorageController.php
28. core/modules/user/user.install
29. core/modules/user/user.module
30. core/modules/user/user.pages.inc
31. core/modules/user/user.tokens.inc
32. core/vendor/doctrine/common/lib/Doctrine/Common/Util/Inflector.php
33. core/vendor/doctrine/common/tests/NativePhpunitTask.php
34. core/vendor/symfony/validator/Symfony/Component/Validator/Constraints/Email.php

String samples prior to patch

Limited to comments and user interface.

1. /core/includes/install.core.inc:2442: // Add the site maintenance account's email address to the list of
2. /core/includes/mail.inc:29: * use user_preferred_langcode(). If you send email based on form values
3. /core/includes/mail.inc:61: * // not send by email.
4. /core/includes/mail.inc:312: * The content of the email as a string with formatting applied.
5. /core/lib/Drupal/Core/TypedData/Type/Email.php:13: * The plain value of Email is the email address represented as PHP string.
6. /core/lib/Drupal/Core/Utility/Token.php:17: * For example: When configuring automated emails, an administrator enters
7. /core/lib/Drupal/Core/Utility/Token.php:18: * standard text for the email. Variables like the title of a node and the date
8. /core/lib/Drupal/Core/Utility/Token.php:19: * the email was sent can be entered as placeholders like [node:title] and
9. /core/lib/Drupal/Core/Utility/Token.php:20: * [date:short]. When a Drupal module prepares to send the email, it can call
10. /core/lib/Drupal/Core/Utility/Token.php:103: * module using tokens in a text-only email might provide a callback to
11. /core/misc/ui/README.md:74: **Make sure the author has a valid name and email address associated with the commit.**
12. /core/modules/action/action.module:485: * Return a form definition so the Send email action can be configured.
13. /core/modules/action/action.module:541: form_set_error('recipient', t('Enter a valid email address or use a token e-mail address such as %author.', array('%author' => '[node:author:mail]')));
14. /core/modules/action/action.module:598: watchdog('action', 'Sent email to %recipient', array('%recipient' => $recipient));
15. /core/modules/action/action.module:601: watchdog('error', 'Unable to send email to %recipient', array('%recipient' => $recipient));
16. /core/modules/comment/comment.tokens.inc:42: 'name' => t("Email address"),
17. /core/modules/comment/comment.tokens.inc:43: 'description' => t("The email address left by the comment author."),
18. /core/modules/contact/lib/Drupal/contact/Tests/ContactAuthenticatedUserTest.php:33: * Tests that name and email fields are not present for authenticated users.
19. /core/modules/contact/lib/Drupal/contact/Tests/ContactAuthenticatedUserTest.php:42: // Ensure that there is no textfield for email.
20. /core/modules/dblog/lib/Drupal/dblog/Tests/DbLogTest.php:259: // Default display includes name and email address; if too long, the email
21. /core/modules/dblog/lib/Drupal/dblog/Tests/DbLogTest.php:259: // Default display includes name and email address; if too long, the email
22. /core/modules/openid/lib/Drupal/openid/Tests/OpenIDRegistrationTest.php:75: $this->assertEqual($user->mail, 'john@example.com', 'User was registered with right email address.');
23. /core/modules/openid/lib/Drupal/openid/Tests/OpenIDRegistrationTest.php:80: $this->assertRaw(t('You must validate your email address for this account before logging in via OpenID.'));
24. /core/modules/openid/lib/Drupal/openid/Tests/OpenIDRegistrationTest.php:126: $this->assertEqual($user->mail, 'john@example.com', 'User was registered with right email address.');
25. /core/modules/openid/lib/Drupal/openid/Tests/OpenIDRegistrationTest.php:267: $this->assertEqual($user->mail, 'john@example.com', 'User was registered with right email address.');
26. /core/modules/openid/openid.module:83: ...legitimate, email verification is still necessary. When...
27. /core/modules/openid/openid.module:266: // Use the email returned by Simple Registration if available.
28. /core/modules/openid/openid.module:274: // If email verification is off, hide the password field and just fill
29. /core/modules/openid/openid.module:756: drupal_set_message(t('You must validate your email address for this account before logging in via OpenID.'));
30. /core/modules/openid/openid.module:782: // If the OpenID provider did not provide both a user name and an email
31. /core/modules/search/search.module:78: ...Administer users permission can search for users by email address. Additionally, users with...
32. /core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.php:3153: * Number of emails to search for string, starting with most recent.
33. /core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.php:3182: $message = format_string('Expected text found in @field of email message: "@expected".', array('@field' => $field_name, '@expected' => $string));
34. /core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.php:3212: $message = format_string('Expected text found in @field of email message: "@expected".', array('@field' => $field_name, '@expected' => $regex));
35. /core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.php:3218: * Outputs to verbose the most recent $count emails sent.
36. /core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.php:3221: * Optional number of emails to output.
37. /core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.php:3227: $this->verbose(t('Email:') . '
    

    ' . print_r($mail, TRUE) . '

    ');

38. /core/modules/system/lib/Drupal/system/Tests/Mail/HtmlToTextTest.php:340: * denominator of Internet email, with lines of no more than 998 characters."
39. /core/modules/system/system.api.php:108: * data, sending email, and intensive file tasks, should use the queue API
40. /core/modules/system/system.api.php:1343: * Alter an email message created with the drupal_mail() function.
41. /core/modules/system/system.api.php:1345: * hook_mail_alter() allows modification of email messages created and sent
42. /core/modules/system/system.api.php:1349: * Email messages sent using functions other than drupal_mail() will not
43. /core/modules/system/system.api.php:1365: * either a custom address or the site-wide default email address.
44. /core/modules/system/system.api.php:1367: * Subject of the email to be sent. This must not contain any newline
45. /core/modules/system/system.api.php:1368: * characters, or the email may not be sent properly.
46. /core/modules/system/system.api.php:1383: * Set to FALSE to abort sending this email message.
47. /core/modules/system/system.api.php:1763: * SMS, Email, pager, syslog, ...etc.
48. /core/modules/system/system.api.php:1869: * default email address when the hook is invoked.
49. /core/modules/system/system.tokens.inc:40: 'description' => t("The administrative email address for the site."),
50. /core/modules/update/update.module:302: // If configured time between notifications elapsed, send email about
51. /core/modules/update/update.module:502: $message['body'][] = t('Your site is currently configured to send these emails when any updates are available. To get notified only for security updates, !url.', array('!url' => $settings_url));
52. /core/modules/update/update.module:505: $message['body'][] = t('Your site is currently configured to send these emails only when security updates are available. To get notified for any available updates, !url.', array('!url' => $settings_url));
53. /core/modules/user/lib/Drupal/user/AccountSettingsForm.php:170: '#description' => t("The e-mail address to be used as the 'from' address for all account notifications listed below. If 'Visitors, but administrator approval is required' is selected above, a notification email will also be sent to this address for any new registrations. Leave empty to use the default system e-mail address (%site-email).", array('%site-email' => $site_config->get('mail'))),
54. /core/modules/user/lib/Drupal/user/AccountSettingsForm.php:178: // These email tokens are shared for all settings, so just define
55. /core/modules/user/lib/Drupal/user/AccountSettingsForm.php:298: // Hide the additional settings when this email is disabled.
56. /core/modules/user/lib/Drupal/user/Plugin/Core/Entity/User.php:76: * The user's email address.
57. /core/modules/user/lib/Drupal/user/Plugin/Core/Entity/User.php:148: * The user's preferred langcode for receiving emails and viewing the site.
58. /core/modules/user/lib/Drupal/user/Plugin/Core/Entity/User.php:162: * The email address used for initial account creation.
59. /core/modules/user/lib/Drupal/user/Plugin/views/field/Mail.php:14: * Field handler to provide acess control for the email field.
60. /core/modules/user/lib/Drupal/user/RegisterFormController.php:129: drupal_set_message(t('The new user %name was created without an email address, so no welcome message was sent.', array('@url' => url($uri['path'], $uri['options']), '%name' => $account->name)));
61. /core/modules/user/lib/Drupal/user/Tests/UserAdminTest.php:114: // Test custom user registration approval email address(es).
62. /core/modules/user/lib/Drupal/user/Tests/UserAdminTest.php:121: // Set the site and notification email addresses.
63. /core/modules/user/lib/Drupal/user/Tests/UserCreateFailMailTest.php:41: // Create a user, but fail to send an email.
64. /core/modules/user/lib/Drupal/user/Tests/UserPasswordResetTest.php:85: // Count email messages before to compare with after.
65. /core/modules/user/lib/Drupal/user/Tests/UserPasswordResetTest.php:103: // Assume the most recent email.
66. /core/modules/user/lib/Drupal/user/Tests/UserRegistrationTest.php:142: $this->assertText(t('The e-mail address @email is already registered.', array('@email' => $duplicate_user->mail)), 'Supplying an exact duplicate email address displays an error message');
67. /core/modules/user/lib/Drupal/user/Tests/UserRegistrationTest.php:144: // Attempt to bypass duplicate email registration validation by adding spaces.
68. /core/modules/user/lib/Drupal/user/Tests/UserRegistrationTest.php:148: $this->assertText(t('The e-mail address @email is already registered.', array('@email' => $duplicate_user->mail)), 'Supplying a duplicate email address with added whitespace displays an error message');
69. /core/modules/user/lib/Drupal/user/Tests/UserValidationTest.php:16: 'description' => 'Verify that username/email validity checks behave as designed.',
70. /core/modules/user/lib/Drupal/user/UserStorageController.php:147: // Send emails after we have the new user object.
71. /core/modules/user/lib/Drupal/user/UserStorageController.php:149: // The user's status is changing; conditionally send notification email.
72. /core/modules/user/user.install:116: 'description' => 'The {language}.langcode that the user prefers for receiving emails and viewing the site.',
73. /core/modules/user/user.install:410: 'description' => 'The {language}.langcode that the user prefers for receiving emails and viewing the site.',
74. /core/modules/user/user.module:306: * Fetches a user object by email address.
75. /core/modules/user/user.module:567: // Administrators can also search in the otherwise private email field, and
76. /core/modules/user/user.module:1523: * the user by email for purposes such as resetting the user's password. In
77. /core/modules/user/user.module:1778: * some additional tokens that can be used in email messages generated by
78. /core/modules/user/user.module:2364: * Conditionally create and send a notification email when a certain
79. /core/modules/user/user.module:2400: // Get the custom site notification email to use as the from email address
80. /core/modules/user/user.module:2403: // If the custom site notification email has not been set, we use the site
81. /core/modules/user/user.pages.inc:53: // Try to load by email.
82. /core/modules/user/user.tokens.inc:33: 'description' => t("The email address of the user account."),
83. /core/vendor/doctrine/common/lib/Doctrine/Common/Util/Inflector.php:29: * original author names and emails are not known
84. /core/vendor/doctrine/common/tests/NativePhpunitTask.php:10: * obtain it through the world-wide-web, please send an email
85. /core/vendor/symfony/validator/Symfony/Component/Validator/Constraints/Email.php:23: public $message = 'This value is not a valid email address.';

> I just wonder what is considered standard in the writing industry these days. Can we do a bit of research (AP style guide, etc.) and see if we should update our standard? That choice of "e-mail" was made many many years ago.

From http://en.wikipedia.org/wiki/Email#Spelling:

e-mail is the most common form in print, and is recommended by some prominent journalistic and technical style guides[citation needed]. According to Corpus of Contemporary American English data, this is the form that appears most frequently in edited, published American English and British English writing.[8]

email is the most common form used online, and is required by IETF Requests for Comment and working groups[9] and increasingly by style guides.[10][11][12] This spelling also appears in most dictionaries.[13][14][15][16][17][18]

That would seem to suggest we use 'email'.

+1 to updating our style guide to use 'email'.

Setting to CNW because regardless of the decision, this will definitely need a reroll :)

Before we update the style guide, we should also file an issue in the Documentation project, because that style guide is for drupal.org documentation, and actually for content on drupal.org in general. If not everyone is on board with the idea...

That sounds like a great idea. I am in support of changing the strings to email. I am happy to re-roll the patch once a consensus is reached.

Great work everyone.

So has this been decided yet? Is it to be "email" or "e-mail" :)

Has not been decided. See #41 - we need to get broader discussion. That hasn't been done. If you want to start the broader discussion,that would be great.

Re-rolled the latest patch.

Moving to documentation and updating the issue summary.

(also +1 for email)

See #44/#41. We need to have a broader discussion on this before we make patches.

Tagging.

Thanks @jhodgdon

I vote email.

Also,

$ grep -nr "email" * | wc -l
     827
$ grep -nr "e-mail" * | wc -l
     272

I feel e-mail is the better choice.

Pro: "email"
- it is more often used in our own code
- there is a trend that authors use this spelling more and more . that is why AP adapted this spelling (http://www.quickanddirtytips.com/education/grammar/e-mail-or-email)

Pro: "e-mail"
- it is our current accepted standard
- it is consistent with words like e-learning, e-economy and X-ray (http://www.future-perfect.co.uk/grammar-tip/is-it-e-mail-email-e-mail-or...)

So I have a light preference for "e-mail", but I am open to change my mind for a small fee ;)

I feel like email is the more mature choice. "e-" stems from a time where anything web was futuristic stuff and seems more and more to get a negative, belittling connotation.

+1 email

Just a quick comment that "email" versus "e-mail" is entirely a style decision which means that, generally speaking, there is no correct choice. It's usually one of those areas where you just pick one and stick with it. Having said that, the one thing that would influence me either way was some data on what Drupal users are actually using in their communications and as a search term and how the search results are impacted by using one term or another.

If you search drupal.org for "email" and "e-mail" its quite striking that "email" is the absolutely overwhelming favourite especially in the forums and issues and is even the strong favourite in the online documentation (which theoretically should be following the style guide).

Inconsistency has an impact when you're performing a search, since Solr is apparently (to my surprise) not treating the two spellings as the same term (55k hits for "email" versus about 8k for "e-mail").

So yeah, the online style guide should probably be updated to reflect the preferred usage of the vast majority of our users. How the issue should be addressed in core is outside my expertise.

Thanks for that Lee!

Core documentation is (in theory) supposed to follow the on-line style guide for questions of grammar, punctuation, and usage.

So... A long time ago (well before I was involved in the Drupal project), someone made the decision to use e-mail, but it looks fairly conclusive that in existing Core docs and on-line drupal.org docs, email is now far more common than e-mail. I agree with Lee that we should update the on-line style guide to reflect the reality of the people in the Drupal project, and also make a patch for Core.

Does anyone find fault with that logic, even if your own personal preference is for "e-mail", or should we go ahead?

I think the outlined path to a patch seems like solid logic.

Do we have to update all of the documentation first or can we roll a patch and then tackle the documentation?

Cheers

Step 1: Agree on the standards.

Step 2: Update the Style Guide document on drupal.org.

Step 3: Make a patch to fix this in Drupal 8, sometime when it would not be to disruptive to other work, because it will touch a lot of files.

Step 4 (if ever): As time goes on, update drupal.org documentation to the new style guide. As noted above, not much of the docs were following the past style guide anyway.

Two data points:

1. The built-in spell-checkers of the major browsers that I have access to, as well as apps like Google Docs, are all marking "e-mail" as a typo and suggest "email" as a replacement instead. More frequent usage in online docs might very well be driven by such tools. (Do you really want to get blamed for typos in your fancy new documentation page? :))
2. I'd be cautious whether the Solr search results for "e-mail" are actually correct, because the search term might have been tokenized into "e" + "mail". Given the substantial difference in results, I'd rather assume that the search yielded all content that contain "mail" (very rare) instead of "e-mail".

Personally, I'm still in favor of "e-mail". I believe that various English grammar style guides are recommending it.

However, given the behavior of spell-checkers not under our control, and also, given that "Email" even managed to find its way and get accepted as a formal word in the official German lexicon/vocabulary (in exactly this spelling), it might be time to confess that we're diverging from the rest of the world by sticking with "e-mail", whether we like it or not. ;)

Pretty sure that @jbloomfield's patch in #45 has some other junk in it.

I don't really care how we do it as long as it is consistent.

This should be easy to implement, mind you this issue has been open since 2010, so perhaps not...

The MLP website does not even know about e-mail. Not that we could not differ from that, but as a translator, I see that all big players in the IT field are changing their strings with e-mail to email (and just making me easy money as a translator ;-) ). I thought the official spelling was changed to email some years ago, but cannot find any info about that, so I guess that was just a recommendation of some groups.
I would still use email, as it is the trend in the IT industry.

The previous patch had way too much overshoot in it. So I went ahead and just created a new one.

If this gets in, then we should probably add a rule to the Drupal coder codesniffer that checks for E-mail and e-mail, as they will eventually make their way back into core without that check.

Always more interesting with the actual patch.

Aw yiss! Serialized blobs in testing code. My favorite.

Updating summary and title. We need to get some more input on this idea before we can adopt it.

Please do not bother making more patches until we have reached consensus.

"Email" is the best route to go. AP Style Guide, New York Times, and Mashable--seems like Drupal ought to be on that list as well. It's definitely common usage now.

http://www.oed.com/view/Entry/60701
https://twitter.com/APStylebook/status/48798366980780033
http://mashable.com/2011/03/18/ap-stylebook-email/
http://grammarist.com/style/e-mail-email/

As said in prior comments, I think it's clear that the world as a whole (not really subject to personal preference anymore) has decided that this is now an actual separate word: email, not a hyphenated compound. I surmise that this global agreement is because everything is basically "electronic" now ;)

FWIW, it's also just a matter of time before we just drop the "e" as well and again just call it "mail" (there's already somewhat of a movement already).

+1 for "email". I can say that our Rutgers official editorial style guide also has it as "email".

In 2011 apparently http://mashable.com/2011/03/18/ap-stylebook-email/

Now they also mention http://mashable.com/2010/04/16/ap-stylebook-website/

For consistency would probably be good to open that up as a new issue if it isn't already. So, #2256367: Consistently use "website" instead of "web site" in Drupal Core docs and UI text

+1 for "email" as well, it seems to be common usage for major sites nowadays.

Ran into these two:

core/modules/system/tests/modules/form_test/form_test.module: '#title' => 'E-Mail address',
core/modules/system/tests/modules/form_test/form_test.routing.yml: _title: 'E-Mail fields'

So here's a new patch.

I'm not seeing any dissenting opinions. Let's give it until Tuesday next week (May 6) for further comment. If no one objects, we can then move over to reviewing the patch and editing the Style docs.

OK... No one objected, after numerous tweets and waiting, etc. I updated:
https://drupal.org/style-guide/content
https://drupal.org/node/338208/revisions/view/6995679/7271151

The patch still needs review, and probably a reroll by now.

72: drupal-email-standardization-950534-ec5b434-72.patch queued for re-testing.

Rerolled - couple of merge conflicts fixed, noticed that we were changing 'edit-site-mail' to 'edit-sitemail' in SiteConfigureForm.php, and found a couple more e-mail examples in the user module.. not sure how those escaped the other patches..

Btw - the e19e644 in the patch filename is the commit against head that this patch applies against for future re-rollers.

Setting status so test bot will check...

77: drupal-email-standardization-950534-e19e644-77.patch queued for re-testing.

woot. Mergefail. Lets try that again.

Looks good. This is a big patch. Good to standardize this.

That was annoying... So many paths changed (to nicer ones, but...)!

Can someone just get this into Core so someone else doesn't have to keep re-rolling this?

85: drupal-email-standardization-950534-2b31335-85.patch queued for re-testing.

Looking at the screen shot in #83... We should *not* be using the word "emails". Email is not a countable noun, just like mail is not a countable noun. It should be "email messages" (to refer to individual messages) or "email" (to refer to the body of mail that is being sent).

@jhodgdon - Let's deal with that in a new issue. I took a quick use of the term emails in this patch and it's all over the place.

I'm fine with that decision but it needs to be dealt with in another issue, this is just about standardizing by removing the "-" as far as I am concerned. I do think we'd want someone to review the changes of emails -> email to see that it makes sense in context.

There are going to be other standardization issues we'll want to deal with like #2256367: Consistently use "website" instead of "web site" in Drupal Core docs and UI text & #44987: [meta] Use the UTF-8 ellipsis character instead of "..." in the user interface. They should be simple changes to make, really... It really shouldn't take 90 comments to make this kind of change.

Well, OK, if that is what you want to do. I am not happy with this patch, but will refrain from reviewing.

To be clear, you would be happy with this patch if it addressed your concern about emails, right?

I created #2276419: [policy] Plural form of "email": "emails" vs. "email messages"

I took a quick look at a few dictionaries online. There doesn't seem to be a clear concensus about this, but certainly we should look out and reference external references.

Pretty weird but, there's a patch that's green that was rolled totally independently within a week of #85 at #1293108: Consistent use of email over e-mail in Drupal.

The good news is that we came to the same conclusion there "email" over "e-mail". The bad news is that it looks like some duplication of work has been going on :(

FWIW, I totally agree that changing pluralisation is out of scope of this patch. If we were changing "e-mail addresses" to "emails" in the patch, I'd agree that's a mistake, but changing "e-mails" to "emails" is still a forward step and avoids scope creep for something that's been outstanding for nearly 4 years already.

Also... try googling "e-mail client". See how many matches you get.

I'll try to help!

Patch doesn't apply anymore :( Re-rolling.

Straight re-roll.

:( there's a new "e-mail" in sites/default/settings.php on line 614. I'll fix...

Oops, never mind. That was *my* settings.php (which was created before applying the patch, and probably a few revisions ago) not default.settings.php.

Given that, it looks like all instances of "e-mail" have been removed from core: grep -r --exclude-dir=.git 'e-mail' . now returns 0 results.

Unfortunately, grammar / pluralization errors have crept in:

./core/includes/mail.inc:35: * when sending emails in a row to multiple users. Hook_mail() abstracts
./core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php:140:      '#description' => $this->t("Automated emails, such as registration information, will be sent from this address. Use an address ending in your site's domain to help prevent these emails from being flagged as spam."),
./core/lib/Drupal/Core/Utility/Token.php:20: * For example: When configuring automated emails, an administrator enters
./core/modules/config_translation/src/Tests/ConfigTranslationUiTest.php:320:    // We get all emails so no need to check inside the loop.
./core/modules/contact/contact.module:166:      $message['body'][] = t("If you don't want to receive such emails, you can change your settings at !recipient-edit-url.", $variables, $options);
./core/modules/contact/src/Controller/ContactController.php:64:    // Check if flood control has been activated for sending emails.
./core/modules/contact/src/Controller/ContactController.php:108:    // Check if flood control has been activated for sending emails.
./core/modules/simpletest/src/InstallerTestBase.php:128:    // tests from sending out emails and collect them in state instead.
./core/modules/simpletest/src/TestBase.php:1159:        $message = $emailCount == 1 ? '1 email was sent during this test.' : $emailCount . ' emails were sent during this test.';
./core/modules/simpletest/src/Tests/MailCaptureTest.php:49:    // Ensure that there is one email in the captured emails array.
./core/modules/simpletest/src/Tests/MailCaptureTest.php:59:    // Send additional emails so more than one email is captured.
./core/modules/simpletest/src/Tests/MailCaptureTest.php:71:    // There should now be 6 emails captured.
./core/modules/simpletest/src/WebTestBase.php:884:    // tests from sending out emails and collect them in state instead.
./core/modules/simpletest/src/WebTestBase.php:2666:   * Gets an array containing all emails sent during this test case.
./core/modules/simpletest/src/WebTestBase.php:2669:   *   An array containing key/value pairs used to filter the emails that are
./core/modules/simpletest/src/WebTestBase.php:3687:   *   Number of emails to search for string, starting with most recent.
./core/modules/simpletest/src/WebTestBase.php:3752:   * Outputs to verbose the most recent $count emails sent.
./core/modules/simpletest/src/WebTestBase.php:3755:   *   Optional number of emails to output.
./core/modules/system/src/Form/SiteInformationForm.php:89:      '#description' => t("The <em>From</em> address in automated emails sent during registration and new password requests, and other notifications. (Use an address ending in your site's domain to help prevent this email being flagged as spam.)"),
./core/modules/update/src/UpdateSettingsForm.php:53:      '#description' => t('Whenever your site checks for available updates and finds new releases, it can notify a list of users via email. Put each address on a separate line. If blank, noemails will be sent.'),
./core/modules/update/update.module:445:    $message['body'][] = t('Your site is currently configured to send these emails when any updates are available. To get notified only for security updates, !url.', array('!url' => $settings_url));
./core/modules/update/update.module:448:    $message['body'][] = t('Your site is currently configured to send these emails only when security updates are available. To get notified for any available updates, !url.', array('!url' => $settings_url));
./core/modules/user/src/AccountForm.php:91:      '#description' => $this->t('A valid email address. All emails from the system will be sent to this address. The email address is not made public and will only be used if you wish to receive a new password or wish to receive certain news or notifications by email.'),
./core/modules/user/src/AccountForm.php:272:      '#description' => $user_language_added ? $this->t("This account's preferred language for emails and site presentation.") : $this->t("This account's preferred language for emails."),
./core/modules/user/src/Entity/User.php:143:      // Send emails after we have the new user object.
./core/modules/user/src/Entity/User.php:462:      ->setDescription(t("The user's preferred language code for receiving emails and viewing the site."));
./core/modules/user/user.menu_links.yml:27:  description: 'Configure default behavior of users, including registration requirements, emails, and fields.'
./core/vendor/doctrine/inflector/lib/Doctrine/Common/Inflector/Inflector.php:27: * original author names and emails are not known.
./sites/default/default.settings.php:619: * caching, JavaScript/CSS compression, re-routing of outgoing emails, and

... there were also a bunch of variable names that referred to "emails", but they're not documentation so I don't think they count.

Okay, after a brief conversation with jhodgdon on IRC, it turns out that I missed that the e-mail/email issue should be reviewed to verify that e-mail/e-mails goes to email/emails only, and on that other issue we decided it was ok to have "emails".

Therefore, given that Testbot came back with a pass on the re-roll from comment 97 and there are no more instances of "e-mail" in core, this is RTBC.

Updating issue summary to be extra-clear that pluralization is out-of-scope.

Whoops, was looking for a "disruptive" tag but couldn't find it and forgot to remove it from the comment form :(

+++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldWidget/EmailDefaultWidget.php
@@ -15,7 +15,7 @@
diff --git a/core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php b/core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php

diff --git a/core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php b/core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php
index e22f5dc..e37cb51 100644

index e22f5dc..e37cb51 100644
--- a/core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php

--- a/core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php
+++ b/core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php

+++ b/core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php
+++ b/core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php
@@ -111,7 +111,7 @@ public function buildForm(array $form, array &$form_state) {

@@ -111,7 +111,7 @@ public function buildForm(array $form, array &$form_state) {
     $form['#attached']['library'][] = 'core/drupal.timezone';
     // We add these strings as settings because JavaScript translation does not
     // work during installation.
-    $js = array('copyFieldValue' => array('edit-site-mail' => array('edit-account-mail')));
+    $js = array('copyFieldValue' => array('edit-sitemail' => array('edit-account-mail')));
     $form['#attached']['js'][] = array('data' => $js, 'type' => 'setting');
 
     // Cache a fully-built schema. This is necessary for any invocation of

As I pointed out in #77, we have to be careful about our global search and replaces, not all instances of *e-mail* should remove the hyphen.

@Mixologic, sorry :S I've removed the offending line and done a much-more-meticulous review to make sure nothing else got accidentally mutated.

As part of the more-meticulous review, I noticed this:

--- a/core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php
+++ b/core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php
@@ -149,7 +149,7 @@ public function buildForm(array $form, array &$form_state) {
-      '#title' => $this->t('E-mail address'),
+      '#title' => $this->t('Email address'),

This got missed earlier because I forgot to pass -i to grep. I've re-checked with grep -r -i --exclude-dir=.git 'e-mail' .: there are no more instances.

+++ b/core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php
@@ -160,6 +160,12 @@ public function buildForm(array $form, array &$form_state) {
+    $form['admin_account']['account']['mail'] = array(
+      '#type' => 'email',
+      '#title' => $this->t('E-mail address'),
+      '#required' => TRUE,
+      '#weight' => -5,
+    );

This form control got duplicated, probably in the re-roll. The attached patch removes it.

+++ b/core/modules/user/user.module
@@ -93,6 +93,8 @@ function user_help($route_name, Request $request) {
+    case 'admin/people/search':
+      return '<p>' . t('Enter a simple pattern ("*" may be used as a wildcard match) to search for a username or email address. For example, one may search for "br" and Drupal might return "brian", "brad", and "brenda@example.com".') . '</p>';

This was in the patch in #85, but there's already #2091359: Update hook_help for Search module to deal with that, so I've removed it in the attached patch.

Whoops, updating issue status.

I was talking about this issue a lot yesterday at the Community Summit at DrupalCon. This is an easy one to get in. It hits so many places though we really just need to get it into Core.

Looks great!

For the record for dinosaurs like me: while it is true that AP used e-mail for a very, very long time they changed it in 2011.

Language evolves.Today we change AP style from e-mail to email, no hyphen. Our editors will announce it at #ACES2011 today.

— AP Stylebook (@APStylebook) March 18, 2011

This patch should be committed during the "Disruptive Patch Workflow" cycle because it's a low-priority patch that makes lots of changes to many different files (i.e.: it'll probably break a bunch of other patches), but at least in RTBC state, it'll get tested every day so we know when/if it breaks.

@mparker17 - no problemo just pointing that out. It's probably because the patch pretty much had to be remade instead of rerolled in #85.

I applied this against the most recent head, and there are no other instances of E-mail in the codebase, and manually inspected all the changes -everything looks good to go.

Lets mark this RTBC, (somebody did that while I was typing...)and it will stay in the queue until such time as it no longer applies - the patch bots will notify us if it needs more re-rolls.

I have also opened a related issue in the coder module to see about adding a check for e-mail to codesniffer so we can detect variances from this policy moving forward [2278995]

er what just happened to that file? I definitely didnt select anything for deletion...

man, i really wish that "needs review" patches also got the same re-review treatment :(

@thedavidmeister: Soon. At any given time there's about 50 RTBC core patches and 1500 Needs Review patches in core alone.. so, its a bit more of a burden on the testbots to re-execute tests that frequently. That being said, there is definitely some momentum in the testbot infrastructure queue that will lead to that being a possibility. There may even someday be a "if this patch is comitted, it will break the patch on issues 1,2, and 45"

I'm pretty aware of the huge number of "needs review" patches there are (there's way more than 1500 >.<), but I also know that many, many of them won't even apply to the latest head. I feel that running the testbots on the "needs review" queue would be a bit initial spam-fest of fails and then quieten down a lot once the 3+ year old patches get shaken out.

This is really off topic for this thread, but if you could link me to an issue where this infrastructure topic is being discussed I'd be grateful as I'm ++ for the direction the testbots are moving in and would love to get in the discussion.

This looks great.

I went through the patch itself and verified that all the changes make sense. Also applied it and then did a grep -Ri "e-mail" and the only occurrence is:

$js = array('copyFieldValue' => array('edit-site-mail' => array('edit-account-mail')));

in core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php as noted above.

Setting to RTBC.

This looks really good to me. As @LinL mentioned, grepping after applying the patch returns the site-mail line from SiteConfigureForm.php which is not a valid reference for the use case we are considering.

Secondly, e-mail is used in the .git/hooks/applypatch-msg.sample and .git/hooks/pre-applypatch.sample files. However, I believe those are within any git repository and are not part of the scope of this patch.

If anyone is installing this patch on a functioning D8 install make sure to use sudo so that you can apply changes to settings.php and default.settings.php. This is not an issue for a fresh pull from git.

+1 RTBC

Ok, getting this in while it's hot.

Committed and pushed to 8.x. Thanks!

That feels great after nearly 3 years. Thanks @webchick for keeping tabs on this. Cheers for all that contributed to this issue.

@Jhodgdon if you would like to point me at the proper documentation pages I would gladly begin updating the docs. As far as I can tell this search would be the place to start.
https://drupal.org/search/site/e-mail?f[0]=ss_meta_type%3Adocumentation

Thanks again everyone!

The style guide has already been updated with this change:
https://drupal.org/style-guide/content

So... As far as updating all of the Community Documentation pages to use email instead of e-mail... I don't think we need to do that right now. As time goes on, hopefully people will update pages that way, but I don't think it's worth the effort to make all the edits. Someone who wants to edit documentation pages, I think, could find better things to do (like making pages clearer, adding new documentation, etc.).

Closed #1996226: Drupal is using E-mail instead of Email as a duplicate.

It's a 5 years old issue, but today grepping for the /\se-mail/ regex pattern in the 8.8.x-dev core/ directory results 50+ occurrences again. (Results on Gitlab)

Only maintainers of this project can reopen issues like this with status "Closed (fixed)".

May I ask any of the maintainers to reopen this issue thread so I can upload a patch to fix these strings in a one-run batch?

Open a new issue instead, and mark this one as Related.

Thanks, so here we go: Maintain policy of using "email" instead of "e-mail" in Drupal