documentation: Modify cases of "[a-zA-Z] e\.g\.," for readability.

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.,
+to create an empty `__init__.py` file in that directory via, for
-`touch zerver/webhooks/helloworld/__init__.py`.
+example, `touch zerver/webhooks/helloworld/__init__.py`.
 
 ## Step 2: Create main webhook code
 

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.,
+1. You should now see the name of your virtualenv preceding your prompt (e.g.,
-   `(zulip-api-py3-venv)`.
+   `(zulip-api-py3-venv)`).
 
 !!! tip ""
 

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

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

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
+(so you can also use, for example, `firefox docs/_build/html/index.html`
-the root of your Zulip checkout).
+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

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

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.,
+You can adjust the deadline for your installation by setting, for
-`SERVER_UPGRADE_NAG_DEADLINE_DAYS = 30 * 21` in
+example, `SERVER_UPGRADE_NAG_DEADLINE_DAYS = 30 * 21` in
 `/etc/zulip/settings.py` and then [restarting the server](../production/settings.md).
 
 ### Operating system support

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
+reject authentication requests (e.g., based on IP address of the
-request, this is where it should happen.
+request), this is where it should happen.
 :::
 
 [django-authenticate-details]: https://docs.djangoproject.com/en/5.0/topics/auth/customizing/#writing-an-authentication-backend

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

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
+list of user IDs correctly. There can be security problems if, for
-event containing direct message content is sent to the entire
+example, an event containing direct message content is sent to the
-organization. However, if an event isn't sent to enough clients,
+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

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
+  several UI-manipulating things including, for example, loading the
-  overlay, and needs to update the hash without re-triggering the open
+  channels overlay, and needs to update the hash without re-triggering
-  animation (etc.).
+  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

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
+Markdown processor, our logic attaches the data to the Markdown
-processor object via e.g., `_md_engine.zulip_db_data`, and then
+processor object via, for example, `_md_engine.zulip_db_data`, and
-individual Markdown rules can access the data from there.
+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,

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
+    for example, where the user closes their last Zulip tab and we get
-    `DELETE /events/{queue_id}` request).
+    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

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

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

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

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
+These records are also useful if you want to, for example, run the
-when you are not connected to the Internet.
+Puppeteer tests when you are not connected to the Internet.

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

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

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.
 

templates/zerver/development/dev_tools.html

@@ -84,7 +84,7 @@
         <h2>Useful management commands</h2>
         <p>Development-specific <a href="https://zulip.readthedocs.io/en/latest/production/management-commands.html">management commands</a> live in <code>zilencer/management/commands</code>.  Highlights include:
             <ul>
-                <li><code>./manage.py populate_db</code>: Rebuilds database. Has options to e.g., create 3K users for testing.</li>
+                <li><code>./manage.py populate_db</code>: Rebuilds database. Has options to, for example, create 3K users for testing.</li>
                 <li><code>./manage.py mark_all_messages_unread</code>: Useful for testing reading messages.</li>
                 <li><code>./manage.py create_realm</code>: Add a new realm. Useful for testing onboarding.</li>
                 <li><code>./manage.py create_user</code>: Add a new user. Useful for testing onboarding.</li>

tools/droplets/README.md

@@ -130,7 +130,7 @@ so they are notified.
    - Check "Monitoring", "IPv6", and "User data"
    - Paste the contents of `tools/droplets/new-droplet-image` into the
      text box which says `Enter user data here...`
-   - Name it e.g., `base-ubuntu-22-04.zulipdev.org`
+   - Name it (e.g., `base-ubuntu-22-04.zulipdev.org`)
 1. Wait for the host to boot.
 1. Wait for the host to complete provisioning and shut down; this will take
    about 15 minutes.