Fixup some punctuation and grammar (#29342)

After noticing one punctuation mistake around "however", I figured there
must be more. So I fixed them, and some other stuff adjacent to them.

Author: jedcunningham

docs/apache-airflow-providers-google/operators/cloud/dataflow.rst

@@ -146,7 +146,7 @@ See: `Configuring PipelineOptions for execution on the Cloud Dataflow service <h
 Asynchronous execution
 """"""""""""""""""""""
 
-Dataflow batch jobs are by default asynchronous - however this is dependent on the application code (contained in the JAR
+Dataflow batch jobs are by default asynchronous; however, this is dependent on the application code (contained in the JAR
 or Python file) and how it is written. In order for the Dataflow job to execute asynchronously, ensure the
 pipeline objects are not being waited upon (not calling ``waitUntilFinish`` or ``wait_until_finish`` on the
 ``PipelineResult`` in your application code).

docs/apache-airflow-providers-http/operators.rst

@@ -49,7 +49,7 @@ the response text back.
 
    For historical reasons, configuring ``HTTPS`` connectivity via HTTP operator is, well, difficult and
    counter-intuitive. The Operator defaults to ``http`` protocol and you can change the schema used by the
-   operator via ``scheme`` connection attribute. However this field was originally added to connection for
+   operator via ``scheme`` connection attribute. However, this field was originally added to connection for
    database type of URIs, where database schemes are set traditionally as first component of URI ``path``.
    Therefore if you want to configure as ``https`` connection via URI, you need to pass ``https`` scheme
    to the SimpleHttpOperator. AS stupid as it looks, your connection URI will look like this:
@@ -58,8 +58,8 @@ the response text back.
    ``https://your_host:443/my_endpoint`` you need to set the endpoint parameter to ``my_endpoint``.
    Alternatively, if you want, you could also percent-encode the host including the ``https://`` prefix,
    and as long it contains ``://`` (percent-encoded ``%3a%2f%2f``), the first component of the path will
-   not be used as scheme. Your URI definition might then look like: ``http://https%3a%2f%2fblue-sea-697d.quartiers047.workers.dev%3a443%2fhttps%2fyour_host:443/``
-   In this case however the ``path`` will not be used at all - you still need to use ``endpoint``
+   not be used as scheme. Your URI definition might then look like ``http://https%3a%2f%2fblue-sea-697d.quartiers047.workers.dev%3a443%2fhttps%2fyour_host:443/``.
+   In this case, however, the ``path`` will not be used at all - you still need to use ``endpoint``
    parameter in the task if wish to make a request with specific path. As counter-intuitive as it is, this
    is historically the way how the operator/hook works and it's not easy to change without breaking
    backwards compatibility because there are other operators build on top of the ``SimpleHttpOperator`` that

docs/apache-airflow-providers/howto/create-update-providers.rst

@@ -246,7 +246,7 @@ In the ``airflow/providers/<NEW_PROVIDER>/provider.yaml`` add information of you
 
 .. note:: Defining your own connection types
 
-    You only need to add ``connection-types`` in case you have some hooks that have customized UI behavior. However
+    You only need to add ``connection-types`` in case you have some hooks that have customized UI behavior. However,
     it is only supported for Airflow 2.2.0. If your providers are also targeting Airflow below 2.2.0 you should
     provide the deprecated ``hook-class-names`` array. The ``connection-types`` array allows for optimization
     of importing of individual connections and while Airflow 2.2.0 is able to handle both definition, the
@@ -272,10 +272,10 @@ Optional provider features
     This feature is available in Airflow 2.3+.
 
 Some providers might provide optional features, which are only available when some packages or libraries
-are installed. Such features will typically result in ``ImportErrors`` however those import errors
+are installed. Such features will typically result in ``ImportErrors``; however, those import errors
 should be silently ignored rather than pollute the logs of Airflow with false warnings. False warnings
 are a very bad pattern, as they tend to turn into blind spots, so avoiding false warnings is encouraged.
-However until Airflow 2.3, Airflow had no mechanism to selectively ignore "known" ImportErrors. So
+However, until Airflow 2.3, Airflow had no mechanism to selectively ignore "known" ImportErrors. So
 Airflow 2.1 and 2.2 silently ignored all ImportErrors coming from providers with actually lead to
 ignoring even important import errors - without giving the clue to Airflow users that there is something
 missing in provider dependencies.

docs/apache-airflow-providers/index.rst

@@ -83,8 +83,8 @@ Logging
 '''''''
 
 The providers can add additional task logging capabilities. By default ``Apache Airflow`` saves logs for
-tasks locally and make them available to Airflow UI via internal http server, however via providers
-you can add extra logging capabilities, where Airflow Logs can be written to a remote service and
+tasks locally and make them available to Airflow UI via internal http server. However, providers
+can add extra logging capabilities, where Airflow Logs can be written to a remote service and
 retrieved from those services.
 
 You can see all task loggers available via community-managed providers in

docs/apache-airflow/administration-and-deployment/lineage.rst

@@ -63,7 +63,7 @@ works.
 
 Inlets can be a (list of) upstream task ids or statically defined as an attr annotated object
 as is, for example, the ``File`` object. Outlets can only be attr annotated object. Both are rendered
-at run time. However the outlets of a task in case they are inlets to another task will not be re-rendered
+at run time. However, the outlets of a task in case they are inlets to another task will not be re-rendered
 for the downstream task.
 
 .. note:: Operators can add inlets and outlets automatically if the operator supports it.

docs/apache-airflow/administration-and-deployment/logging-monitoring/errors.rst

@@ -95,9 +95,9 @@ environment variables are passed but also all existing environment variables are
 ``SUBPROCESS_`` prefix added. This happens also for all other subprocesses.
 
 This behaviour can be disabled by setting ``default_integrations`` sentry configuration parameter to
-``False`` which disables ``StdlibIntegration``. This however also disables other default integrations
-and you need to enable them manually if you want to get them enabled,
-see `Sentry Default Integrations <https://docs.sentry.io/platforms/python/guides/wsgi/configuration/integrations/default-integrations/>`_
+``False`` which disables ``StdlibIntegration``. However, this also disables other default integrations,
+so you need to enable them manually if you want them to remain enabled
+(see `Sentry Default Integrations <https://docs.sentry.io/platforms/python/guides/wsgi/configuration/integrations/default-integrations/>`_).
 
 .. code-block:: ini
 

docs/apache-airflow/administration-and-deployment/scheduler.rst

@@ -111,7 +111,7 @@ outline of the scheduling loop is:
 - Select schedulable TaskInstances, and whilst respecting Pool limits and other concurrency limits, enqueue
   them for execution
 
-This does however place some requirements on the Database.
+This does, however, place some requirements on the Database.
 
 .. _scheduler:ha:db_requirements:
 
@@ -274,7 +274,7 @@ There are several areas of resource usage that you should pay attention to:
   which dramatically decreases performance. Note that Airflow Scheduler in versions prior to ``2.1.4``
   generated a lot of ``Page Cache`` memory used by log files (when the log files were not removed).
   This was generally harmless, as the memory is just cache and could be reclaimed at any time by the system,
-  however in version ``2.1.4`` and beyond, writing logs will not generate excessive ``Page Cache`` memory.
+  however, in version ``2.1.4`` and beyond, writing logs will not generate excessive ``Page Cache`` memory.
   Regardless - make sure when you look at memory usage, pay attention to the kind of memory you are observing.
   Usually you should look at ``working memory``(names might vary depending on your deployment) rather
   than ``total memory used``.
@@ -314,8 +314,8 @@ Scheduler Configuration options
 """""""""""""""""""""""""""""""
 
 The following config settings can be used to control aspects of the Scheduler.
-However you can also look at other non-performance-related scheduler configuration parameters available at
-:doc:`../configurations-ref` in ``[scheduler]`` section.
+However, you can also look at other non-performance-related scheduler configuration parameters available at
+:doc:`../configurations-ref` in the ``[scheduler]`` section.
 
 - :ref:`config:scheduler__max_dagruns_to_create_per_loop`
 

docs/apache-airflow/administration-and-deployment/security/secrets/secrets-backend/index.rst

@@ -114,6 +114,6 @@ Adapt to non-Airflow compatible secret formats for connections
 The default implementation of Secret backend requires use of an Airflow-specific format of storing
 secrets for connections. Currently most community provided implementations require the connections to
 be stored as JSON or the Airflow Connection URI format (see
-:doc:`apache-airflow-providers:core-extensions/secrets-backends`). However some organizations may need to store the credentials (passwords/tokens etc) in some other way, for example if the same credentials store needs to be used for multiple data platforms, or if you are using a service with a built-in mechanism of rotating the credentials that does not work with the Airflow-specific format.
+:doc:`apache-airflow-providers:core-extensions/secrets-backends`). However, some organizations may need to store the credentials (passwords/tokens etc) in some other way. For example, if the same credentials store needs to be used for multiple data platforms, or if you are using a service with a built-in mechanism of rotating the credentials that does not work with the Airflow-specific format.
 In this case you will need to roll your own secret backend as described in the previous chapter,
 possibly extending an existing secrets backend and adapting it to the scheme used by your organization.

docs/apache-airflow/administration-and-deployment/security/webserver.rst

@@ -66,9 +66,6 @@ following CLI commands to create an account:
         --role Admin \
         --email [email protected]
 
-It is however possible to switch on authentication by either using one of the supplied
-backends or creating your own.
-
 To deactivate the authentication and allow users to be identified as Anonymous, the following entry
 in ``$AIRFLOW_HOME/webserver_config.py`` needs to be set with the desired role that the Anonymous
 user will have by default:

docs/apache-airflow/authoring-and-scheduling/dynamic-task-mapping.rst

@@ -169,7 +169,7 @@ As well as a single parameter it is possible to pass multiple parameters to expa
     # add(x=8, y=5)
     # add(x=8, y=10)
 
-This would result in the add task being called 6 times. Please note however that the order of expansion is not guaranteed.
+This would result in the add task being called 6 times. Please note, however, that the order of expansion is not guaranteed.
 
 Mapping with non-TaskFlow operators
 ===================================
@@ -522,7 +522,7 @@ There are two limits that you can place on a task:
 
   If you wish to not have a large mapped task consume all available runner slots you can use the ``max_active_tis_per_dag`` setting on the task to restrict how many can be running at the same time.
 
-  Note however that this applies to all copies of that task against all active DagRuns, not just to this one specific DagRun.
+  Note, however, that this applies to all copies of that task against all active DagRuns, not just to this one specific DagRun.
 
   .. code-block:: python