Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

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

Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit is contained in:
Anders Kaseorg 2020-08-10 17:20:10 -07:00 committed by Tim Abbott
parent 64b2212c23
commit 6dea085187
28 changed files with 40 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/development/remote.md
View File

@ -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

2
docs/development/using.md
View File

@ -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.

4
docs/overview/changelog.md
View File

@ -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.

4
docs/production/authentication-methods.md
View File

@ -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

2
docs/production/deployment.md
View File

@ -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.

2
docs/production/email-gateway.md
View File

@ -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:

4
docs/production/mobile-push-notifications.md
View File

@ -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,

4
docs/production/security-model.md
View File

@ -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

4
docs/production/upgrade-or-modify.md
View File

@ -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`.

2
docs/subsystems/analytics.md
View File

@ -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

2
docs/subsystems/markdown.md
View File

@ -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.

2
docs/subsystems/settings.md
View File

@ -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

2
docs/testing/testing-with-django.md
View File

@ -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.

2
templates/corporate/zephyr-mirror.html
View File

@ -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>

2
templates/two_factor/_wizard_forms.html
View File

@ -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 %}

2
templates/zerver/config_error.html
View File

@ -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 %}

2
templates/zerver/emails/followup_day1.source.html
View File

@ -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>

2
templates/zerver/emails/followup_day1.txt
View File

@ -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 }}

2
templates/zerver/help/change-organization-url.md
View File

@ -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.

2
templates/zerver/help/import-from-gitter.md
View File

@ -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).

2
templates/zerver/login.html
View File

@ -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>

2
templates/zerver/social_auth_select_email.html
View File

@ -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>

4
zerver/forms.py
View File

@ -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))

6
zerver/management/commands/export.py
View File

@ -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.

8
zerver/tests/test_auth_backends.py
View File

@ -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, [

2
zerver/tests/test_signup.py
View File

@ -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)

4
zerver/views/auth.py
View File

@ -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

2
zproject/backends.py
View File

@ -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.