docs: Correct “login” as a verb to “log in”.

Signed-off-by: Anders Kaseorg <anders@zulip.com>

docs/development/remote.md

@@ -44,7 +44,7 @@ account.)
 * You can add the user to the sudo group by running the command
 `usermod -aG sudo zulipdev`.
 * Finally, you can switch to the user by running the command `su -
-zulipdev` (or just login to that user using `ssh`).
+zulipdev` (or just log in to that user using `ssh`).
 
 ## Setting up the development environment
 

docs/development/using.md

@@ -66,7 +66,7 @@ the development environment][authentication-dev-server].
 * Once the development server (`run-dev.py`) is running, you can visit
   <http://localhost:9991/> in your browser.
 * By default, the development server homepage just shows a list of the
-  users that exist on the server and you can login as any of them by
+  users that exist on the server and you can log in as any of them by
   just clicking on a user.
     * This setup saves time for the common case where you want to test
     something other than the login process.

docs/overview/changelog.md

@@ -877,7 +877,7 @@ Zulip installations; it has minimal changes for existing servers.
 - Upgraded to modern versions of most of our stale dependencies.
 - Updated our CSS toolchain to support hot module reloading.
 - Updated numerous pages within the /help/ site.
-- We no longer require re-authing to signup after trying to login with
+- We no longer require re-authing to signup after trying to log in with
   an OAuth authentication backend (GitHub or Google).
 - Made major improvements to the Help Center.
 - Improved system for configuring the S3 file uploads backend.
@@ -1415,7 +1415,7 @@ Zulip apps.
 * Improved Markdown support for bulleted lists.
 * Improved copy-to-clipboard support in various places.
 * Improved subject lines of missed message emails.
-* Improved handling of users trying to login with OAuth without an account.
+* Improved handling of users trying to log in with OAuth without an account.
 * Improved UI of off-the-Internet errors to not be hidden in narrow windows.
 * Improved rate-limiting errors to be more easily machine-readable.
 * Parallelized the backend test suite; now runs 1600 tests in <30s.

docs/production/authentication-methods.md

@@ -131,7 +131,7 @@ it as follows:
 
 6. [Restart the Zulip server](../production/settings.md) to ensure
 your settings changes take effect.  The Zulip login page should now
-have a button for SAML authentication that you can use to login or
+have a button for SAML authentication that you can use to log in or
 create an account (including when creating a new organization).
 
 7. If the configuration was successful, the server's metadata can be
@@ -369,7 +369,7 @@ the Zulip server).  Zulip will then treat users that are disabled via
 the "Disable Account" feature in Active Directory as deactivated in
 Zulip.
 
-Users disabled in active directory will be immediately unable to login
+Users disabled in active directory will be immediately unable to log in
 to Zulip, since Zulip queries the LDAP/Active Directory server on
 every login attempt.  The user will be fully deactivated the next time
 your `manage.py sync_ldap_user_data` cron job runs (at which point

docs/production/deployment.md

@@ -122,7 +122,7 @@ run the commands in `scripts/setup/create-db.sql` to:
 
 * Create a database called `zulip`.
 * Create a user called `zulip`.
-* Now login with the `zulip` user to create a schema called
+* Now log in with the `zulip` user to create a schema called
   `zulip` in the `zulip` database. You might have to grant `create`
   privileges first for the `zulip` user to do this.
 

docs/production/email-gateway.md

@@ -53,7 +53,7 @@ using an [HTTP reverse proxy][reverse-proxy]).
     1 hostname.example.com
     ```
 
-1.  Login to your Zulip server; the remaining steps all happen there.
+1. Log in to your Zulip server; the remaining steps all happen there.
 
 1. Add `, zulip::postfix_localmail` to `puppet_classes` in
    `/etc/zulip/zulip.conf`.  A typical value after this change is:

docs/production/mobile-push-notifications.md

@@ -50,10 +50,10 @@ following.  Please follow the instructions carefully:
 * [Configure mobile push notifications to always be sent][mobile-notifications-always]
   (normally they're only sent if you're idle, which isn't ideal for
   this sort of testing).
-* On an Android device, download and login to the
+* On an Android device, download and log in to the
 [Zulip Android app](https://play.google.com/store/apps/details?id=com.zulipmobile).
 If you were already logged in before configuring the server, you'll
-need to logout first, since the app only registers for push
+need to log out first, since the app only registers for push
 notifications on login.
 * Hit the home button, so Zulip is running in the background, and then
 have **another user** send you a **private message** (By default,

docs/production/security-model.md

@@ -35,7 +35,7 @@ announcement).
 * Zulip requires CSRF tokens in all interactions with the web API to
   prevent CSRF attacks.
 
-* The preferred way to login to Zulip is using an SSO solution like
+* The preferred way to log in to Zulip is using an SSO solution like
   Google Auth, LDAP, or similar, but Zulip also supports password
   authentication.  See
   [the authentication methods documentation](../production/authentication-methods.md)
@@ -184,7 +184,7 @@ strength allowed is controlled by two settings in
   * Incoming webhook bots can only send messages into Zulip.
   * Outgoing webhook bots and Generic bots can essentially do anything a
     non-administrator user can, with a few exceptions (e.g. a bot cannot
-    login to the web application, register for mobile push
+    log in to the web application, register for mobile push
     notifications, or create other bots).
   * API super user bots can send messages that appear to have been sent by
     another user. They also have the ability to see the names of all

docs/production/upgrade-or-modify.md

@@ -36,7 +36,7 @@ to a new Zulip release:
     repository](https://github.com/zulip/zulip) using
     `tools/build-release-tarball`.
 
-1. Login to your Zulip and run as root:
+1. Log in to your Zulip and run as root:
 
     ```
     /home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-VERSION.tar.gz
@@ -458,7 +458,7 @@ git diff 2.0.4 acme-branch
 git push origin +acme-branch
 ```
 
-* Login to your Zulip server and configure and use
+* Log in to your Zulip server and configure and use
 [upgrade-zulip-from-git][] to install the changes; remember to
 configure `git_repo_url` to point to your fork on GitHub and run it as
 `upgrade-zulip-from-git acme-branch`.

docs/subsystems/analytics.md

@@ -162,7 +162,7 @@ The main testing approach for the /stats page UI is manual testing.
 For most UI testing, you can visit `/stats/realm/analytics` while
 logged in as Iago (this is the server administrator view of stats for
 a given realm).  The only piece that you can't test here is the "Me"
-buttons, which won't have any data.  For those, you can instead login
+buttons, which won't have any data.  For those, you can instead log in
 as the `shylock@analytics.ds` in the `analytics` realm and visit
 `/stats` there (which is only a bit more work).  Note that the
 `analytics` realm is a shell with no streams, so you'll only want to

docs/subsystems/markdown.md

@@ -70,7 +70,7 @@ this file:
 If you're going to manually test some changes in the frontend Markdown
 implementation, the easiest way to do this is as follows:
 
-1. Login to your development server.
+1. Log in to your development server.
 2. Stop your Zulip server with Ctrl-C, leaving the browser open.
 3. Compose and send the messages you'd like to test.  They will be
    locally echoed using the frontend rendering.

docs/subsystems/settings.md

@@ -152,6 +152,6 @@ replaced with realm settings:
 * Which authentication methods are allowed should probably appear in
   both places; in server settings indicating the capabilities of the
   server, and in the realm settings indicating which methods the realm
-  administrator wants to allow users to login with.
+  administrator wants to allow users to log in with.
 
 [doc-newfeat]: ../tutorials/new-feature-tutorial.md

docs/testing/testing-with-django.md

@@ -317,7 +317,7 @@ endpoints support a JSON interface.  Regardless of the interface, an
 endpoint test generally follows this pattern:
 
 - Set up the data.
-- Login with `self.login()` or set up an API key.
+- Log in with `self.login()` or set up an API key.
 - Use a Zulip test helper to hit the endpoint.
 - Assert that the result was either a success or failure.
 - Check the data that comes back from the endpoint.

templates/corporate/zephyr-mirror.html

@@ -56,7 +56,7 @@ mirror script instead of using Webathena.</p>
     session, and use `/mit/kchen/bin/cont-renew-notify` to continually
     renew your Kerberos tickets for up to a week; each week, it will
     send you a Zephyr/Zulip letting you know that you need to renew
-    your tickets.  To do so, login to the server that you setup the
+    your tickets.  To do so, log in to the server that you setup the
     screen session on and use the following procedure:</p>
 
     <ol>

templates/two_factor/_wizard_forms.html

@@ -11,7 +11,7 @@
     <p>
         Use this form for entering backup tokens for logging in.
         These tokens have been generated for you to print and keep safe. Please
-        enter one of these backup tokens to login to your account.
+        enter one of these backup tokens to log in to your account.
     </p>
 {% endif %}
 

templates/zerver/config_error.html

@@ -12,7 +12,7 @@
                     <br>
                     {% if error_name == "ldap_error_realm_is_none" %}
                         {% trans %}
-                        You are trying to login using LDAP without creating an
+                        You are trying to log in using LDAP without creating an
                         organization first. Please use EmailAuthBackend to create
                         your organization and then try again.
                         {% endtrans %}

templates/zerver/emails/followup_day1.source.html

@@ -22,7 +22,7 @@
         {% if ldap_username %}
         <li>{{ _('Username:') }} {{ ldap_username }}<br></li>
         {% else %}
-        <li>{{ _('Use your LDAP account to login') }}<br></li>
+        <li>{{ _('Use your LDAP account to log in') }}<br></li>
         {% endif %}
     {% else %}
         <li>{{ _('Email:') }} {{ email }}<br></li>

templates/zerver/emails/followup_day1.txt

@@ -13,7 +13,7 @@
 {% if ldap_username %}
 * {{ _('Username:') }} {{ ldap_username }}
 {% else %}
-* {{ _('Use your LDAP account to login') }}
+* {{ _('Use your LDAP account to log in') }}
 {% endif %}
 {% else %}
 * {{ _('Email:') }} {{ email }}

templates/zerver/help/change-organization-url.md

@@ -4,7 +4,7 @@ Zulip supports changing the URL for an organization.  Changing the
 organization URL is a disruptive operation for users:
 
 * Users will be logged out of existing sessions on the web, mobile and
-  desktop apps and need to login again.
+  desktop apps and need to log in again.
 * Any [API clients](/api) or [integrations](/integrations) will need
   to be updated to point to the new organization URL.
 

templates/zerver/help/import-from-gitter.md

@@ -101,7 +101,7 @@ to mark the appropriate users as administrators.
   `{github_username}@users.noreply.github.com`.
 
   Since one cannot receive email at those noreply email addresses,
-  imported users will need to use GitHub authentication to login to
+  imported users will need to use GitHub authentication to log in to
   Zulip and will be unable to receive email notifications until they
   [change their Zulip email address](/help/change-your-email-address).
 

templates/zerver/login.html

@@ -33,7 +33,7 @@ page can be easily identified in it's respective JavaScript file. -->
                 {% if no_auth_enabled %}
                     <div class="alert">
                         <p>No authentication backends are enabled on this
-                        server yet, so it is impossible to login!</p>
+                        server yet, so it is impossible to log in!</p>
 
                         <p>See the <a href="https://zulip.readthedocs.io/en/latest/production/install.html#step-3-configure-zulip">Zulip
                         authentication documentation</a> to learn how to configure authentication backends.</p>

templates/zerver/social_auth_select_email.html

@@ -67,7 +67,7 @@
         </p>
         <p>
             {% trans %}
-            To use one of these to login to Zulip, you must first
+            To use one of these to log in to Zulip, you must first
             <a href="https://github.com/settings/emails">verify it with GitHub.</a>
             {% endtrans %}
         </p>

zerver/forms.py

@@ -346,7 +346,7 @@ class OurAuthenticationForm(AuthenticationForm):
             try:
                 realm = get_realm(subdomain)
             except Realm.DoesNotExist:
-                logging.warning("User %s attempted to password login to nonexistent subdomain %s",
+                logging.warning("User %s attempted password login to nonexistent subdomain %s",
                                 username, subdomain)
                 raise ValidationError("Realm does not exist")
 
@@ -368,7 +368,7 @@ class OurAuthenticationForm(AuthenticationForm):
                 raise ValidationError(mark_safe(DEACTIVATED_ACCOUNT_ERROR))
 
             if return_data.get("invalid_subdomain"):
-                logging.warning("User %s attempted to password login to wrong subdomain %s",
+                logging.warning("User %s attempted password login to wrong subdomain %s",
                                 username, subdomain)
                 raise ValidationError(mark_safe(WRONG_SUBDOMAIN_ERROR))
 

zerver/management/commands/export.py

@@ -26,7 +26,7 @@ class Command(ZulipBaseCommand):
 
     Things that are not exported:
     * Confirmation and PreregistrationUser (transient tables)
-    * Sessions (everyone will need to login again post-export)
+    * Sessions (everyone will need to log in again post-export)
     * Users' passwords and API keys (users will need to use SSO or reset password)
     * Mobile tokens for APNS/GCM (users will need to reconnect their mobile devices)
     * ScheduledEmail (Not relevant on a new server)
@@ -38,7 +38,7 @@ class Command(ZulipBaseCommand):
     * Passwords will not be transferred.  They will all need to go
       through the password reset flow to obtain a new password (unless
       they intend to only use e.g. Google Auth).
-    * Users will need to logout and re-login to the Zulip desktop and
+    * Users will need to log out and re-log in to the Zulip desktop and
       mobile apps.  The apps now all have an option on the login page
       where you can specify which Zulip server to use; your users
       should enter <domain name>.
@@ -65,7 +65,7 @@ class Command(ZulipBaseCommand):
     * Use `./manage.py import` to import the realm
 
     * Use `./manage.py reactivate_realm` to reactivate the realm, so
-      users can login again.
+      users can log in again.
 
     * Inform the users about the things broken above.
 

zerver/tests/test_auth_backends.py

@@ -815,7 +815,7 @@ class SocialAuthBase(DesktopFlowTestingLib, ZulipTestCase):
         * is_signup: Whether we're testing the social flow for
           /register (True) or /login (False).  This is important
           because we need to verify behavior like the
-          "Continue to registration" if you try to login using an
+          "Continue to registration" if you try to log in using an
           account that doesn't exist but is allowed to signup.
         * next: Parameter passed through in production authentication
           to redirect the user to (e.g.) the specific page in the webapp
@@ -2385,7 +2385,7 @@ class GitHubAuthBackendTest(SocialAuthBase):
         if expect_choose_email_screen:
             # As GitHub authenticates multiple email addresses,
             # we'll have an additional screen where the user selects
-            # which email address to login using (this screen is a
+            # which email address to log in using (this screen is a
             # "partial" state of the python-social-auth pipeline).
             #
             # TODO: Generalize this testing code for use with other
@@ -2795,7 +2795,7 @@ class GitHubAuthBackendTest(SocialAuthBase):
         )])
 
     def test_github_unverified_email_with_existing_account(self) -> None:
-        # check if a user is denied to login if the user manages to
+        # check if a user is denied to log in if the user manages to
         # send an unverified email that has an existing account in
         # organisation through `email` GET parameter.
         account_data_dict = self.get_account_data_dict(email='hamlet@zulip.com', name=self.name)
@@ -5036,7 +5036,7 @@ class LDAPBackendTest(ZulipTestCase):
             self.assertEqual(response.status_code, 302)
             self.assertEqual(response.url, reverse('config_error', kwargs={'error_category_name': 'ldap'}))
             response = self.client_get(response.url)
-            self.assert_in_response('You are trying to login using LDAP '
+            self.assert_in_response('You are trying to log in using LDAP '
                                     'without creating an',
                                     response)
         self.assertEqual(warn_log.output, [

zerver/tests/test_signup.py

@@ -631,7 +631,7 @@ class LoginTest(ZulipTestCase):
             result = self.login_with_return(self.example_email("hamlet"), "xxx",
                                             subdomain="invalid")
         self.assertEqual(warn_log.output, [
-            'WARNING:root:User hamlet@zulip.com attempted to password login to nonexistent subdomain invalid'
+            'WARNING:root:User hamlet@zulip.com attempted password login to nonexistent subdomain invalid'
         ])
         self.assertEqual(result.status_code, 404)
         self.assert_in_response("There is no Zulip organization hosted at this subdomain.", result)

zerver/views/auth.py

@@ -241,13 +241,13 @@ def login_or_register_remote_user(request: HttpRequest, result: ExternalAuthResu
     browser to the appropriate place:
 
     * The logged-in app if the user already has a Zulip account and is
-      trying to login, potentially to an initial narrow or page that had been
+      trying to log in, potentially to an initial narrow or page that had been
       saved in the `redirect_to` parameter.
     * The registration form if is_signup was set (i.e. the user is
       trying to create a Zulip account)
     * A special `confirm_continue_registration.html` "do you want to
       register or try another account" if the user doesn't have a
-      Zulip account but is_signup is False (i.e. the user tried to login
+      Zulip account but is_signup is False (i.e. the user tried to log in
       and then did social authentication selecting an email address that does
       not have a Zulip account in this organization).
     * A zulip:// URL to send control back to the mobile or desktop apps if they

zproject/backends.py

@@ -1184,7 +1184,7 @@ def social_associate_user_helper(backend: BaseAuth, return_data: Dict[str, Any],
     first_name = kwargs['details'].get('first_name')
     last_name = kwargs['details'].get('last_name')
     if all(name is None for name in [full_name, first_name, last_name]) and backend.name != "apple":
-        # Apple authentication provides the user's name only the very first time a user tries to login.
+        # Apple authentication provides the user's name only the very first time a user tries to log in.
         # So if the user aborts login or otherwise is doing this the second time,
         # we won't have any name data. So, this case is handled with the code below
         # setting full name to empty string.