docs: fix typos

2026-08-30 16:58:03 +08:00 · 2026-06-09 21:45:52 +00:00
parent b7896c13a6
commit 01afe742e3
17 changed files with 30 additions and 30 deletions
@@ -23,7 +23,7 @@ ecosystem.
 ## Mount Functions

 In what most people think of as a "standard" Vue application there would be only one place that Vue
-is mounted to the HTML environment, and that would be in a main.j or an app.js. Most modern
+is mounted to the HTML environment, and that would be in a main.js or an app.js. Most modern
 single-page applications only have one starting point like that.

 However, we are incrementally replacing old Backbone views, so in its current state, Galaxy may have
@@ -10,7 +10,7 @@ Heading Levels are used by screen readers, and other software, to get a rough id

 - When increasing a heading level, do not skip Levels.

- Do not use a headings level to determine it's size. Use one of the heading utility classes (e.g. `h-lg`) instead.
+- Do not use a headings level to determine its size. Use one of the heading utility classes (e.g. `h-lg`) instead.

 - Do not use a heading tag to make a non-heading text large. Use a heading utility class on a `<span>` instead.

@@ -3,7 +3,7 @@
 ---

 We are using components in two very distinct ways. The first, "normal", kind of component will
-probably look familiar to anybody whis is already passingly familiar with Vue. Here the relevant
+probably look familiar to anybody who is already passingly familiar with Vue. Here the relevant
 information comes in as properties, any internal variables get defined in "data", changes go out as
 events.

@@ -18,7 +18,7 @@ events.

 In this example, we've created a component whose job is to deal with loading and updating the doodad
 object. Notice that there is no markup inside the DoodadProvider other than the explicit renderless
-component we previously made, but you are free to putput whatever you want in there, accessing the
+component we previously made, but you are free to put whatever you want in there, accessing the
 doodad and saveDoddad properties as desired, as well as any other local data with the only
 restriction that Vue needs a single root element in which to render.

@@ -231,7 +231,7 @@ Add spaces between the `script`, `template` and `style` blocks.
 > </template>
 >
 > <style lang="scss" scoped>
-> // stlye stuff...
+> // style stuff...
 > </style>
 > ```
 >
@@ -245,7 +245,7 @@ Add spaces between the `script`, `template` and `style` blocks.
 >     <!--template stuff-->
 > </template>
 > <style lang="scss" scoped>
-> // stlye stuff...
+> // style stuff...
 > </style>
 > ```

@@ -35,7 +35,7 @@ These modules must be enabled in the Apache config. The main proxy directives, `
 Additionally, these directions are written for Apache 2.4+. Apache 2.4 for EL 6 can be obtained from the [CentOS SCLo
 SIG Repo][sclo-sig-repo]. Otherwise, your system package manager's version of Apache should be suitable.

-Ensure that the `mod_headers`, `mod_rewrite` and `mod_proxy`modules are loaded. Although not
+Ensure that the `mod_headers`, `mod_rewrite` and `mod_proxy` modules are loaded. Although not
 required, the configuration examples also use `mod_deflate` and `mod_expires` for increased client/server performance,
 so these should also be enabled.

@@ -1,7 +1,7 @@
 # Carbon Emissions Reporting

 Galaxy can estimate the carbon footprint of each job you run. The carbon emissions reporting can be 
-configured for each galaxy instance to allow for more accurate results. The following options can
+configured for each Galaxy instance to allow for more accurate results. The following options can
 be set:

 * [Geographical server location](#geographical-server-location)
@@ -15,7 +15,7 @@ United States [Environmental Protection Agency (EPA)](https://www.epa.gov/energy

 ## Geographical server location
 The `geographical_server_location_code` flag is an [ISO 3166-2](https://en.wikipedia.org/wiki/ISO_3166-2) string specifying the
-location of your galaxy instance, with the only exception being `GLOBAL`, which specifies that global average values are to be used.
+location of your Galaxy instance, with the only exception being `GLOBAL`, which specifies that global average values are to be used.
 Each valid code corresponds to a location name and a specific carbon intensity value. The corresponding flags 
 (`geographical_server_location_name` and `carbon_intensity`) are automatically set and will be displayed to the client when carbon 
 emissions are reported. The more accurate the location the better the estimates. In all cases, it is assumed that all jobs are run on
@@ -25,7 +25,7 @@ a server in the same location as the one specified in `geographical_server_locat

 ## Power usage effectiveness
 [Power usage effectiveness](https://en.wikipedia.org/wiki/Power_usage_effectiveness), or PUE for short, is a ratio specifying
-how efficiently the data centre hosting your galaxy server used energy. It is essentially your server's 'indirect' energy usage.
+how efficiently the data centre hosting your Galaxy server used energy. It is essentially your server's 'indirect' energy usage.
 Galaxy uses a default PUE of `1.67`. If you would like to set a custom value, you can [calculate a PUE value as follows](https://en.wikipedia.org/wiki/Power_usage_effectiveness).

 ## Feature toggling
@@ -4,7 +4,7 @@
 Conda for Tool Dependencies
 ===========================

-.. note:: This document describes configuring Galaxy using YAML based configuraiton
+.. note:: This document describes configuring Galaxy using YAML based configuration
  options. For Galaxy instances before version 18.01, `this variant
  <https://docs.galaxyproject.org/en/release_17.09/admin/conda_faq.html>`__ of this
  document will be more directly relatable.
@@ -64,7 +64,7 @@ Additional configuration files and their purposes are:
  internally.
 - ``build_sites.yml``: Controls which display applications are available and their configuration paths
 - ``containers_conf.yml``: Configures the beta Galaxy containers interface, currently only used by Galaxy Interactive
-  Environments, and only neccesary for Docker Swarm support.
+  Environments, and only necessary for Docker Swarm support.
 - ``dependency_resolvers_conf.xml``: Describes how Galaxy tools (which are typically just descriptions of how to run a
  particular command line tool) should locate their dependencies (the command line tool) that are not part of the tool.
  See the `Dependency Resolvers documentation <dependency_resolvers>` for more.
@@ -364,7 +364,7 @@ admins might want to control.

 .. note::

-   For the execution of jobs Galaxy already implement the `support for using
+   For the execution of jobs Galaxy already implements the `support for using
   tarballs of container images
   <https://github.com/galaxyproject/galaxy/blob/c517e805771cc16807dfe675075a13fe6343f01f/lib/galaxy/tool_util/deps/container_classes.py#L319>`_.
   from ``container_image_cache_path`` (set in galaxy.yml) or the destination
@@ -16,7 +16,7 @@ In order to understand the naming and structure of these three components it mig
 to look in the history. Tool data was organized in tabular `loc` that contained metadata and paths
 of the data. Those files were installed with the tool and could be accessed with the
 [`from_file`](https://docs.galaxyproject.org/en/master/dev/schema.html#from-file) mechanism from tools.
-Since each tool version had it's own `loc` file the maintenance was difficult. With tool data tables
+Since each tool version had its own `loc` file the maintenance was difficult. With tool data tables
 an additional abstraction layer was introduced that is used from tools via
 [`from_datatable`](https://docs.galaxyproject.org/en/master/dev/schema.html#from-data-table).

@@ -294,7 +294,7 @@ mapping_files

 skip_availability_check
    Set to ``true`` to skip filtering module dependencies using ``module avail`` and attempt to load each
-    module listed in the depedencies (default: ``false``).
+    module listed in the dependencies (default: ``false``).
    This setting should be used when during dependency resolution modules are not listed in ``module avail``,
    but can be expected to be present when using ``module load`` in the job script,  such as child modules
    in hierarchical module systems. Note: the order in which dependencies are listed could be important.
@@ -342,7 +342,7 @@ default_indicator

 skip_availability_check
    Set to ``true`` to skip filtering module dependencies using ``module avail`` and attempt to load each
-    module listed in the depedencies (default: ``false``).
+    module listed in the dependencies (default: ``false``).
    This setting should be used when during dependency resolution modules are not listed in ``module avail``,
    but can be expected to be present when using ``module load`` in the job script,  such as child modules
    in hierarchical module systems. Note: the order in which dependencies are listed could be important.
@@ -376,6 +376,6 @@ It is highly experimental, undocumented, and unmaintained, and likely to be drop
 Brewed Tool Shed Package Resolver
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-The ``brewed_tool_shed`` dependency resolver was an attmept to resolve tool shed packages that had been auto converted
+The ``brewed_tool_shed`` dependency resolver was an attempt to resolve tool shed packages that had been auto converted
 to the tool shed. It is highly experimental, undocumented, unmaintained, and will almost certainly be removed from the
 code base.
@@ -697,7 +697,7 @@
 :Description:
    Location of files available for a short time as downloads (short
    term storage). This directory is exclusively used for serving
-    dynamically generated downloadable content. Galaxy may uses the
+    dynamically generated downloadable content. Galaxy may use the
    new_file_path parameter as a general temporary directory and that
    directory should be monitored by a tool such as tmpwatch in
    production environments. short_term_storage_dir on the other hand
@@ -1288,7 +1288,7 @@
    destination level for heterogeneous clusters. conda job resolution
    requires bash or zsh so if this is switched to /bin/sh for
    instance - conda resolution should be disabled. Containerized jobs
-    always use /bin/sh - so more maximum portability tool authors
+    always use /bin/sh - for maximum portability tool authors
    should assume generated commands run in sh.
 :Default: ``/bin/bash``
 :Type: str
@@ -1323,7 +1323,7 @@

 :Description:
    Set this to true to attempt to resolve bio.tools metadata for
-    tools for tool not resovled via biotools_content_directory.
+    tools for tool not resolved via biotools_content_directory.
 :Default: ``false``
 :Type: bool

@@ -7,7 +7,7 @@ We removed support for running Galaxy under uWSGI in Galaxy release 22.05.
 We made this move because uWSGI support for newer Python versions has been problematic and because
 we have modernized the API portion of our backend. The Galaxy web application is now an ASGI application
 driven by [FastAPI](https://fastapi.tiangolo.com/) and [Starlette](https://www.starlette.io/).
-This enables numerous important features that were not be possible (or were more complicated to set up)
+This enables numerous important features that were not possible (or were more complicated to set up)
 otherwise. Importantly, [FastAPI's documentation](https://fastapi.tiangolo.com/tutorial/) is very good and
 should increase developer productivity.

@@ -10,7 +10,7 @@ and enabling a Galaxy User to gain access to content inside in real-time.
 How Galaxy InteractiveTools work
 --------------------------------

-A InteractiveTool is defined in the same familiar way as standard Galaxy Tools,
+An InteractiveTool is defined in the same familiar way as standard Galaxy Tools,
 but are specified with ``tool_type="interactive"``, and providing additional
 entry point information:

@@ -202,7 +202,7 @@ An example ``job_conf.yml`` file as seen in ``config/job_conf.yml.interactivetoo
          default_destination_id: local


-The Galaxy currently contains a sizable collection of **InteractiveTools** directly in the
+Galaxy currently contains a sizable collection of **InteractiveTools** directly in the
 code base. To be enabled, they need to be commented in or added to the ``config/tool_conf.xml``:

 .. code-block:: xml
@@ -213,7 +213,7 @@ code base. To be enabled, they need to be commented in or added to the ``config/
    </toolbox>


-A InteractiveTool is defined in the same familiar way as standard Galaxy Tools,
+An InteractiveTool is defined in the same familiar way as standard Galaxy Tools,
 but are specified with ``tool_type="interactive"``, and providing additional
 entry point information:

@@ -268,7 +268,7 @@ server within an InteractiveTool container now must serve the contents under a p
 2.  Absolute links. Unfortunately many relevant services are implemented with absolute links, i.e. starting
    at the top-level ``/``. For such InteractiveTools to work with path-based URLs the contained web server
    needs to be configured with the path prefix/entry point path under which the content should be served. Two issues then
-    needs to be considered:
+    need to be considered:

    a.  How to inject the path prefix into the InteractiveTool at run-time?

@@ -395,7 +395,7 @@ In both nginx config examples, you might want to replace localhost with your ser
 Job runner configuration in production
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-InteractiveTools have been enabled for the Condor, Slurm, Pulsar and Kuberneters job runner.
+InteractiveTools have been enabled for the Condor, Slurm, Pulsar and Kubernetes job runner.
 A destination configuration for Condor may look like this:

 .. code-block:: xml
@@ -40,9 +40,9 @@ To safely delete unused histories and their associated records, please use the `
 Deleting old galaxy_session records
 -----------------------------------

-Each time Galaxy is accessed, a galaxy_session record is created, even when the user is annonymous. Over time, Galaxy accumulates such records. Deleting such records will declutter the database and free up space. 
+Each time Galaxy is accessed, a galaxy_session record is created, even when the user is anonymous. Over time, Galaxy accumulates such records. Deleting such records will declutter the database and free up space. 

-To safely delete such records, please use the galaxy-delete-sessions script. By default, a galaxy_session record should be at least a month old to be considered safe to delete (which is determinded by the value of its ``update_time`` field). 
+To safely delete such records, please use the galaxy-delete-sessions script. By default, a galaxy_session record should be at least a month old to be considered safe to delete (which is determined by the value of its ``update_time`` field). 

 .. code-block:: console

@@ -77,7 +77,7 @@ While the structure is similar, several key differences exist:
 To enable this feature:

 1. Set `enable_beta_tool_formats: true` in your Galaxy configuration.
-2. Create a role of type `Custom Tool Execution` in the admin user interdace.
+2. Create a role of type `Custom Tool Execution` in the admin user interface.
 3. Assign users or groups to this role.

 ## Sharing User-Defined Tools
@@ -44,7 +44,7 @@ of the static checking that can be done for the Galaxy backend.
 To further document your API and allow other developers to see how it functions,
 new API functionality should include functional tests. These functional
 tests should be implemented in Python and added to either the API test suite
-or the integration test suite. Checkout the :doc:`Writing Tests for Galaxy <writing_tests>`
+or the integration test suite. Check out the :doc:`Writing Tests for Galaxy <writing_tests>`
 documentation for more information on developing tests for Galaxy.

 .. note::