diff --git a/api_docs/incoming-webhooks-walkthrough.md b/api_docs/incoming-webhooks-walkthrough.md index 9d61bf6127..0e214ef8ec 100644 --- a/api_docs/incoming-webhooks-walkthrough.md +++ b/api_docs/incoming-webhooks-walkthrough.md @@ -69,10 +69,10 @@ integration uses. ## Step 1: Initialize your webhook python package In the `zerver/webhooks/` directory, create new subdirectory that will -contain all of the corresponding code. In our example it will be +contain all of the corresponding code. In our example, it will be `helloworld`. The new directory will be a python package, so you have -to create an empty `__init__.py` file in that directory via e.g., -`touch zerver/webhooks/helloworld/__init__.py`. +to create an empty `__init__.py` file in that directory via, for +example, `touch zerver/webhooks/helloworld/__init__.py`. ## Step 2: Create main webhook code diff --git a/api_docs/writing-bots.md b/api_docs/writing-bots.md index 8867bfb16c..cf3712d06d 100644 --- a/api_docs/writing-bots.md +++ b/api_docs/writing-bots.md @@ -41,8 +41,8 @@ On this page you'll find: 1. Run the command provided in the final output of the `provision` process to enter the new virtualenv. The command will be of the form `source .../activate`. -1. You should now see the name of your virtualenv preceding your prompt e.g., - `(zulip-api-py3-venv)`. +1. You should now see the name of your virtualenv preceding your prompt (e.g., + `(zulip-api-py3-venv)`). !!! tip "" diff --git a/docs/development/setup-recommended.md b/docs/development/setup-recommended.md index 88c12ab1f4..ce32b42040 100644 --- a/docs/development/setup-recommended.md +++ b/docs/development/setup-recommended.md @@ -955,7 +955,7 @@ The `vagrant up` command basically does the following: To debug such errors, you can log in to the Vagrant guest machine by running `vagrant ssh`, which should present you with a standard shell -prompt. You can debug interactively by using e.g., +prompt. You can debug interactively by using, for example, `cd zulip && ./tools/provision`, and then running the individual subcommands that failed. Once you've resolved the problem, you can rerun `tools/provision` to proceed; the provisioning system is diff --git a/docs/development/using.md b/docs/development/using.md index 84780fdfa4..b8b5835b62 100644 --- a/docs/development/using.md +++ b/docs/development/using.md @@ -13,7 +13,7 @@ the development environment][authentication-dev-server]. ## Common - Zulip's `main` branch moves quickly, and you should rebase - constantly with e.g., + constantly with, for example, `git fetch upstream; git rebase upstream/main` to avoid developing on an old version of the Zulip codebase (leading to unnecessary merge conflicts). diff --git a/docs/documentation/overview.md b/docs/documentation/overview.md index e468159cce..48fba04585 100644 --- a/docs/documentation/overview.md +++ b/docs/documentation/overview.md @@ -58,8 +58,8 @@ documentation using: and then opening `http://127.0.0.1:9991/docs/index.html` in your browser. The raw files are available at `file:///path/to/zulip/docs/_build/html/index.html` in your browser -(so you can also use e.g., `firefox docs/_build/html/index.html` from -the root of your Zulip checkout). +(so you can also use, for example, `firefox docs/_build/html/index.html` +from the root of your Zulip checkout). If you are adding a new page to the table of contents, you will want to modify `docs/index.md` and run `make clean` before `make html`, so diff --git a/docs/git/zulip-tools.md b/docs/git/zulip-tools.md index f091a14eb3..cbec6890c6 100644 --- a/docs/git/zulip-tools.md +++ b/docs/git/zulip-tools.md @@ -120,7 +120,7 @@ HEAD is now at 5a1e982 tools: Update clean-branches to clean review branches. `tools/push-to-pull-request` is primarily useful for maintainers who are merging other users' commits into a Zulip repository. After doing `reset-to-pull-request` or `fetch-pull-request` and making some -changes, you can push a branch back to a pull request with e.g., +changes, you can push a branch back to a pull request with, for example, `tools/push-to-pull-request 1234`. This is useful for a few things: - Getting CI to run and enabling you to use the GitHub "Merge" buttons diff --git a/docs/overview/release-lifecycle.md b/docs/overview/release-lifecycle.md index bbe22148b6..21a4062650 100644 --- a/docs/overview/release-lifecycle.md +++ b/docs/overview/release-lifecycle.md @@ -143,8 +143,8 @@ The nag will appear only to organization administrators starting a month before the deadline; after that, it will appear for all users on the server. -You can adjust the deadline for your installation by setting e.g., -`SERVER_UPGRADE_NAG_DEADLINE_DAYS = 30 * 21` in +You can adjust the deadline for your installation by setting, for +example, `SERVER_UPGRADE_NAG_DEADLINE_DAYS = 30 * 21` in `/etc/zulip/settings.py` and then [restarting the server](../production/settings.md). ### Operating system support diff --git a/docs/production/authentication-methods.md b/docs/production/authentication-methods.md index 744c02574d..d9a454a995 100644 --- a/docs/production/authentication-methods.md +++ b/docs/production/authentication-methods.md @@ -1165,8 +1165,8 @@ If you need to use this feature in combination with those backends, you should make your logic be applied when processing the `ZulipDummyBackend` - which is the final layer of the authentication checks for whether authentication should succeed. If you want to -reject authentication requests e.g., based on IP address of the -request, this is where it should happen. +reject authentication requests (e.g., based on IP address of the +request), this is where it should happen. ::: [django-authenticate-details]: https://docs.djangoproject.com/en/5.0/topics/auth/customizing/#writing-an-authentication-backend diff --git a/docs/production/export-and-import.md b/docs/production/export-and-import.md index 91ca9c067b..9b80bfc826 100644 --- a/docs/production/export-and-import.md +++ b/docs/production/export-and-import.md @@ -433,7 +433,8 @@ recommend starting with sending one to yourself for testing: ./manage.py send_password_reset_email -u username@example.com ``` -and then once you're ready, you can email them to everyone using e.g., +and then once you're ready, you can email them to everyone using, +for example: ```bash ./manage.py send_password_reset_email -r '' --all-users diff --git a/docs/subsystems/events-system.md b/docs/subsystems/events-system.md index e72bb2851a..434ebbec36 100644 --- a/docs/subsystems/events-system.md +++ b/docs/subsystems/events-system.md @@ -72,9 +72,9 @@ Usually, this list of users is one of 3 things: or the people on a direct message thread. It is the responsibility of the caller of `send_event` to choose the -list of user IDs correctly. There can be security problems if e.g., an -event containing direct message content is sent to the entire -organization. However, if an event isn't sent to enough clients, +list of user IDs correctly. There can be security problems if, for +example, an event containing direct message content is sent to the +entire organization. However, if an event isn't sent to enough clients, there will likely be user-visible real-time sync bugs. Most of the hard work in event generation is about defining consistent diff --git a/docs/subsystems/hashchange-system.md b/docs/subsystems/hashchange-system.md index 2d359089b6..6fef63d67c 100644 --- a/docs/subsystems/hashchange-system.md +++ b/docs/subsystems/hashchange-system.md @@ -32,9 +32,9 @@ different flows: will be visited). - The user clicking some in-app click handler (e.g., "Channel settings" for an individual channel), that potentially does - several UI-manipulating things including e.g., loading the channels - overlay, and needs to update the hash without re-triggering the open - animation (etc.). + several UI-manipulating things including, for example, loading the + channels overlay, and needs to update the hash without re-triggering + the open animation (etc.). - Within an overlay like the channels overlay, the user clicks to another part of the overlay, which should update the hash but not re-trigger loading the overlay (which would result in a confusing diff --git a/docs/subsystems/markdown.md b/docs/subsystems/markdown.md index acf959576b..f532e010cc 100644 --- a/docs/subsystems/markdown.md +++ b/docs/subsystems/markdown.md @@ -146,9 +146,9 @@ At a backend code level, these are controlled by the `message_realm` object and other arguments passed into `do_convert` (`sent_by_bot`, `translate_emoticons`, `mention_data`, etc.). Because Python-Markdown doesn't support directly passing arguments into the -Markdown processor, our logic attaches these data to the Markdown -processor object via e.g., `_md_engine.zulip_db_data`, and then -individual Markdown rules can access the data from there. +Markdown processor, our logic attaches the data to the Markdown +processor object via, for example, `_md_engine.zulip_db_data`, and +then individual Markdown rules can access the data from there. For non-message contexts (e.g., an organization's profile (aka the thing on the right-hand side of the login page), channel descriptions, diff --git a/docs/subsystems/notifications.md b/docs/subsystems/notifications.md index 2c8a5b2931..59a6aa7772 100644 --- a/docs/subsystems/notifications.md +++ b/docs/subsystems/notifications.md @@ -72,8 +72,8 @@ as follows: `receiver_is_off_zulip` returns `True`, which checks whether the user has any current events system clients registered to receive `message` events. This check is done immediately (handling soft disconnects, - where e.g., the user closes their last Zulip tab and we get the - `DELETE /events/{queue_id}` request). + for example, where the user closes their last Zulip tab and we get + the `DELETE /events/{queue_id}` request). - The `receiver_is_off_zulip` check is effectively repeated when event queues are garbage-collected (in `missedmessage_hook`) by looking for whether the queue being garbage-collected was the only diff --git a/docs/subsystems/pointer.md b/docs/subsystems/pointer.md index e5bc164ba8..e6fc35bc0d 100644 --- a/docs/subsystems/pointer.md +++ b/docs/subsystems/pointer.md @@ -53,7 +53,7 @@ channels.) ### Unnarrow: previous sequence -When you unnarrow using e.g., the `a` key, you will automatically be +When you unnarrow using, for example, the `a` key, you will automatically be taken to the same message that was selected in the Combined feed view before you narrowed, unless in the narrow you read new messages, in which case you will be jumped forward to the first unread and non-muted diff --git a/docs/subsystems/presence.md b/docs/subsystems/presence.md index 3540b6ab3e..c311009a78 100644 --- a/docs/subsystems/presence.md +++ b/docs/subsystems/presence.md @@ -50,7 +50,3 @@ about that data structure: - The `status_from_timestamp` function in `web/src/presence.js` is useful sample code; the `OFFLINE_THRESHOLD_SECS` check is critical to correct output. -- We provide the data for e.g., whether the user was online on their - desktop or the mobile app, but for a basic client, you will likely - only want to parse the "aggregated" key, which shows the summary - answer for "is this user online". diff --git a/docs/subsystems/queuing.md b/docs/subsystems/queuing.md index f453400b9c..f76f1471f7 100644 --- a/docs/subsystems/queuing.md +++ b/docs/subsystems/queuing.md @@ -40,7 +40,8 @@ To add a new queue processor: processor. This suffices to test your queue worker in the Zulip development environment (`tools/run-dev` will automatically restart the queue processors and start running your new queue processor code). You can also run a single - queue processor manually using e.g., `./manage.py process_queue --queue=user_activity`. + queue processor manually using, for example, + `./manage.py process_queue --queue=user_activity`. - So that supervisord will know to run the queue processor in production, you will need to add to the `queues` variable in diff --git a/docs/subsystems/realms.md b/docs/subsystems/realms.md index 7029e785ca..a233140691 100644 --- a/docs/subsystems/realms.md +++ b/docs/subsystems/realms.md @@ -92,5 +92,5 @@ lookup should still work even if you disable proxy for 127.0.0.1 testsubdomain.zulipdev.com ``` -These records are also useful if you want to e.g., run the Puppeteer tests -when you are not connected to the Internet. +These records are also useful if you want to, for example, run the +Puppeteer tests when you are not connected to the Internet. diff --git a/docs/subsystems/schema-migrations.md b/docs/subsystems/schema-migrations.md index 686162063c..fc0e59dcd6 100644 --- a/docs/subsystems/schema-migrations.md +++ b/docs/subsystems/schema-migrations.md @@ -63,7 +63,7 @@ migrations. - **Atomicity**. By default, each Django migration is run atomically inside a transaction. This can be problematic if one wants to do something in a migration that touches a lot of data and would best - be done in batches of e.g., 1000 objects (e.g., a `Message` or + be done in batches of, for example, 1000 objects (e.g., a `Message` or `UserMessage` table change). There is a [useful Django feature][migrations-non-atomic] that makes it possible to add `atomic=False` at the top of a `Migration` class and thus not have diff --git a/docs/subsystems/settings.md b/docs/subsystems/settings.md index 5a340ec88c..392e53a0a1 100644 --- a/docs/subsystems/settings.md +++ b/docs/subsystems/settings.md @@ -152,7 +152,7 @@ want those settings. ### Testing non-default settings -You can write tests for settings using e.g., +You can write tests for settings using, for example, `with self.settings(TERMS_OF_SERVICE=None)`. However, this only works for settings which are checked at runtime, not settings which are only accessed in initialization of Django (or Zulip) internals diff --git a/docs/tutorials/writing-views.md b/docs/tutorials/writing-views.md index ae5482d74b..b092ac6460 100644 --- a/docs/tutorials/writing-views.md +++ b/docs/tutorials/writing-views.md @@ -193,7 +193,7 @@ REQ also helps us with request variable validation. For example: not automatically marshall the input from JSON). - Since there is no need to JSON-encode strings, usually simply - `my_string=REQ()` is correct. One can pass e.g., + `my_string=REQ()` is correct. One can pass, for example, `str_validator=check_string_in(...)` where one wants to run a validator on the value of a string. diff --git a/templates/zerver/development/dev_tools.html b/templates/zerver/development/dev_tools.html index 92bb602c7d..0d36ab4cfa 100644 --- a/templates/zerver/development/dev_tools.html +++ b/templates/zerver/development/dev_tools.html @@ -84,7 +84,7 @@

Useful management commands

Development-specific management commands live in zilencer/management/commands. Highlights include: