Add codespell support (config, workflow to detect/not fix) and make it fix few typos

.codespellrc

@@ -0,0 +1,7 @@
+[codespell]
+# Ref: https://github.com/codespell-project/codespell#using-a-config-file
+skip = .git*,*.svg,*.css,.codespellrc,*.ai
+check-hidden = true
+# lines with é -- non-English; names
+ignore-regex = (.*[àéç].*|\b(Tung|Tru|Ganes)\b)
+ignore-words-list = nd,ontop,recuse

.github/workflows/codespell.yml

@@ -0,0 +1,25 @@
+# Codespell configuration is within .codespellrc
+---
+name: Codespell
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+permissions:
+  contents: read
+
+jobs:
+  codespell:
+    name: Check for spelling errors
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: Annotate locations with typos
+        uses: codespell-project/codespell-problem-matcher@v1
+      - name: Codespell
+        uses: codespell-project/actions-codespell@v2

.pre-commit-config.yaml

@@ -3,3 +3,9 @@ repos:
     rev: v4.4.0
     hooks:
     -   id: trailing-whitespace
+
+- repo: https://github.com/codespell-project/codespell
+  # Configuration for codespell is in .codespellrc
+  rev: v2.4.0
+  hooks:
+  - id: codespell

EULA.md

@@ -638,7 +638,7 @@ included as well, but this information in reports or any info collected about ha
 X.509 standard encryption information. They also can be used to digitally sign files and macros to verify the integrity and origin of the file contents. The
 software retrieves certificates and updates certificate revocation lists using the Internet, when available.
                 • Windows Application Certification Kit. To ensure you have the latest certification tests, when launched this software periodically checks a
-Windows Application Certification Kit file on download.microsft.com to see if an update is available.  If an update is found, you are prompted and provided a
+Windows Application Certification Kit file on download.microsoft.com to see if an update is available.  If an update is found, you are prompted and provided a
 link to a web site where you can download the update. You may use the Windows Application Certification Kit solely to test your programs before you submit
 them for a potential Microsoft Windows Certification and for inclusion on the Microsoft Windows Store. The results you receive are for informational purposes
 only. Microsoft has no obligation to either (i) provide you with a Windows Certification for your programs and/or ii) include your program in the Microsoft

docs/_scripts/update_ui_sections_docs.py

@@ -50,7 +50,7 @@ def generate_dependencies_graph(options):
     dep_graph : DepGraph
         Result dependency graph constructed by pydeps.
     dot_src : str
-        Result dependecy graph description using .dot format.
+        Result dependency graph description using .dot format.
         It can return `None` depending on the options passed.
     graph_content : bytes
         Result dependency graph in binary format.
@@ -179,11 +179,11 @@ def generate_mermaid_diagram(
             https://mermaid.js.org/syntax/flowchart.html#interaction
         The default is None.
     graph_title : str, optional
-        Accesible title for the graph. For more info see:
+        Accessible title for the graph. For more info see:
             https://mermaid.js.org/config/accessibility.html#accessible-title-and-description
         The default is None.
     graph_description : str, optional
-        Accesible description for the graph. The default is None.
+        Accessible description for the graph. The default is None.
 
     Returns
     -------
@@ -326,7 +326,7 @@ def generate_docs_ui_section(
     mermaid_graph_base_properties,
 ):
     """
-    Generate the needed content for a UI section page as well as a fomatted
+    Generate the needed content for a UI section page as well as a formatted
     page for the section.
 
     Parameters

docs/community/team.md

@@ -69,6 +69,6 @@ Read more about napari’s [mission and values](https://napari.org/stable/commun
     - The CZI Imaging Tech Team, through an effort led by Justin Kiggins, has created [napari-hub.org](https://www.napari-hub.org/), a site to make discovering and sharing napari plugins easier.
     - CZI has launched a [grant program](https://chanzuckerberg.com/rfa/napari-plugin-grants/) to help accelerate the napari plugin developer community.
 
-The current representative of the Insitutional and Funding Partner Advisory Council on the napari steering council is Kyle I. S. Harrington.
+The current representative of the Institutional and Funding Partner Advisory Council on the napari steering council is Kyle I. S. Harrington.
 
 If you or your organization are interested in also supporting the napari project and becoming an Institutional and Funding Partner, please email the napari steering council at `napari-steering-council@googlegroups.com`.

docs/developers/architecture/napari_models.md

@@ -107,7 +107,7 @@ def _update_display(event):
 # register our callback with the model
 dims.events.ndisplay.connect(_update_display)
 
-# now, everytime dims.ndisplay is changed, _update_display is called
+# now, every time dims.ndisplay is changed, _update_display is called
 dim.ndisplay = 3
 ```
 

docs/developers/contributing/documentation/docs_deployment.md

@@ -36,7 +36,7 @@ through several CI workflows detailed below.
         - Pulls in sources from `napari/napari`, builds docs, then uploads as an
           artifact named 'html' to this repository (`napari/docs`).
         - This is triggered on every Pull Request and shows up as a "Build & Deploy PR
-          Docs / Build & Uplod Artifact" check on the PR.
+          Docs / Build & Upload Artifact" check on the PR.
         - **job:** `deploy`
         - Downloads the artifact from the `build-and-upload` job and deploys the html
           to GitHub pages at the `gh-pages` branch of

docs/developers/contributing/documentation/index.md

@@ -408,11 +408,11 @@ of your pull request:
 
 2. Click on **Summary** on the top left corner:
 
-![Summary link in the "Build & Deploy PR Docs / Build & Uplod Artifact" GitHub Action page](../../../_static/images/doc-ci-2.png)
+![Summary link in the "Build & Deploy PR Docs / Build & Upload Artifact" GitHub Action page](../../../_static/images/doc-ci-2.png)
 
 3. Scroll down to **Artifacts** and click on **html** to download the built documentation:
 
-!["html" link in the Artifacts section of the "Build & Deploy PR Docs / Build & Uplod Artifact" GitHub Action page is highlighted](../../../_static/images/doc-ci-3.png)
+!["html" link in the Artifacts section of the "Build & Deploy PR Docs / Build & Upload Artifact" GitHub Action page is highlighted](../../../_static/images/doc-ci-3.png)
 
 4. Extract the compressed archive and open the `html/index.html` file on your preferred browser.
    You can also use Python's `http.server` module to open a local server on
@@ -580,7 +580,7 @@ block is present in all contributed examples.
 
 ### Cross-referencing Gallery examples
 
-If you want to generate links to Gallery examples from anywhere in the docs, then the cross-referencing format you use will depend on the format of the doc you are writing. Note that the gallery examples live in `/gallery` despite being in `napari/examples` because [`docs/docs/conf.py`](https://github.com/napari/docs/blob/main/docs/conf.py) specificies that examples are built into the `gallery` directory. The [Sphinx cross-reference namespace](https://sphinx-gallery.github.io/stable/advanced.html#know-your-gallery-files) is generated with the `sphx_glr` prefix, then path separators are converted to underscores, for example `/gallery/add_image.py` becomes `_gallery_add_image.py` to get the end result `sphx_glr_gallery_add_image.py`. 
+If you want to generate links to Gallery examples from anywhere in the docs, then the cross-referencing format you use will depend on the format of the doc you are writing. Note that the gallery examples live in `/gallery` despite being in `napari/examples` because [`docs/docs/conf.py`](https://github.com/napari/docs/blob/main/docs/conf.py) specifies that examples are built into the `gallery` directory. The [Sphinx cross-reference namespace](https://sphinx-gallery.github.io/stable/advanced.html#know-your-gallery-files) is generated with the `sphx_glr` prefix, then path separators are converted to underscores, for example `/gallery/add_image.py` becomes `_gallery_add_image.py` to get the end result `sphx_glr_gallery_add_image.py`. 
 
 - For `.md` files (myst, used in the majority of docs), use the `{ref}` directive. ``{ref}`sphx_glr_gallery_add_image.py` `` displays as: {ref}`sphx_glr_gallery_add_image.py`
 - For `.py` files (rst, used in the example gallery), cross-reference with the `:ref:` directive: `` :ref:`sphx_glr_gallery_example.py` ``.

docs/developers/contributing/translations.md

@@ -197,10 +197,10 @@ Since `f-strings` do not work with localizable strings, we loose their
 convenience and have to use `str.format`. However, when using deferred
 translations, we need to be able to use any variables the original string
 needs to be able to render itself. To handle this, the `trans` helpers
-provide the ability to receive any extra keyword arguments whcih will be
+provide the ability to receive any extra keyword arguments which will be
 used for rendering the deferred strings on demand.
 
-An example of how this works with Spanish and defered string yields:
+An example of how this works with Spanish and deferred string yields:
 
 ```python
 from napari.utils.translations import trans

docs/developers/coredev/packaging.md

@@ -146,7 +146,7 @@ welcome_image: resources/napari_1227x600.png  # bg image with the napari logo on
 welcome_file: resources/osx_pkg_welcome.rtf  # rendered text in the first screen
 conclusion_text: ""  # set to an empty string to revert constructor customizations back to system's
 readme_text: ""  # set to an empty string to revert constructor customizations back to system's
-signing_identity_name: "Apple Developer ID: ..."  # Name of our installer signing certicate
+signing_identity_name: "Apple Developer ID: ..."  # Name of our installer signing certificate
 
 # windows-specific config
 welcome_image: resources/napari_164x314.png  # logo image for the first screen

docs/developers/coredev/release.md

@@ -231,7 +231,7 @@ Please make sure a correct build for the problematic release is available before
 
 ## Post release: update the documentation
 
-The [napari docs](https://napari.org) are versioned, meaning that each release has its own documentation, selected throught the version switcher dropdown. Once you tag a new version in the `napari/napari` repo, the [`build_and_deploy.yml` workflow](https://github.com/napari/docs/blob/main/.github/workflows/build_and_deploy.yml) will automatically create a new folder for this version number in the `gh-pages` branch of the `napari/napari.github.io` repo.
+The [napari docs](https://napari.org) are versioned, meaning that each release has its own documentation, selected through the version switcher dropdown. Once you tag a new version in the `napari/napari` repo, the [`build_and_deploy.yml` workflow](https://github.com/napari/docs/blob/main/.github/workflows/build_and_deploy.yml) will automatically create a new folder for this version number in the `gh-pages` branch of the `napari/napari.github.io` repo.
 
 Next, you need to do the following:
 

docs/howtos/extending/magicgui.md

@@ -400,7 +400,7 @@ The consequence of each type is described below:
 #### Returning a `Layer` subclass
 
 If you use a {class}`~napari.layers.Layer` subclass as a *return* annotation on a
-`magicgui` function, napari will interpet it to mean that the layer returned
+`magicgui` function, napari will interpret it to mean that the layer returned
 from the function should be added to the viewer.  The object returned from the
 function must be an actual {class}`~napari.layers.Layer` instance.
 
@@ -478,7 +478,7 @@ example). In this case, you may use a return type annotation of one the special
 returned by your function to be turned into the corresponding
 {class}`~napari.layers.Layer` type, and added to the viewer.
 
-For example, in combination with the {attr}`~napari.types.ImageData` paramater
+For example, in combination with the {attr}`~napari.types.ImageData` parameter
 annotation [described above](annotating-as-napari-types-data):
 
 ```{code-cell} python

docs/howtos/layers/labels.md

@@ -184,7 +184,7 @@ layer:
   The `color picker` can be used to select another color at any time. Click the
   color picker tool then click on the existing color in the labels layer you
   would like to use. That color now appears on the label bar as the selected
-  color. If the color does not exist in the label color pallette, it defaults
+  color. If the color does not exist in the label color palette, it defaults
   to 0 and a checkerboard pattern appears in the thumbnail on the label bar to
   represent the transparent color.
 

docs/howtos/layers/points.md

@@ -166,7 +166,7 @@ layer:
   whose properties you want to change, otherwise you will just be initializing
   the property for the next point to add. Select the point you want to change,
   then click the thumbnail next to `face color:` or `border color:` to select or
-  create a color from the pallette.
+  create a color from the palette.
 
 * Display text
 

docs/howtos/layers/shapes.md

@@ -60,7 +60,7 @@ All shapes are edited in the same way:
 
 4. Change the face or edge color by clicking on the thumbnail to the right of
    `face color:` or `edge color:` and choosing or creating a color from the
-   pallette.
+   palette.
 5. Change the edge width of a shape or the width of a line or path by clicking
    the circle next to `edge width:` and dragging it to a new width.
 6. Move the shape by dragging it.
@@ -267,7 +267,7 @@ are used. i.e. You can't remove a vertex before you have created a shape.
   Select the `Add path` tool from the layer controls panel or by pressing the
   `t` key when the shapes layer is selected. The tool can be used to draw freeform, 
   complex paths using the mouse or tablet. Importantly, the paths will still consist 
-  of vertexes and will be editable like all other Shapes.
+  of vertices and will be editable like all other Shapes.
   :::{dropdown} More details on the lasso and path tool
   ```{include} ../../_templates/details_polygon_path_tool.md
   ```
@@ -298,7 +298,7 @@ are used. i.e. You can't remove a vertex before you have created a shape.
   whose properties you want to change, otherwise you will just be initializing
   the color for the next shape to add. Select the shape you want to change,
   click the thumbnail next to `face color:` or `edge color:` to select or create
-  a color from the pallette.
+  a color from the palette.
 
 * Display text
 

docs/howtos/layers/vectors.md

@@ -114,7 +114,7 @@ first, then explore the editing options the GUI provides.
     * Cycle allows the color to be set via a color cycle over an attribute.
     * Colormap allows the color to be set via a color map over an attribute.
   * Edge color - click the thumbnail next to `edge color:` to select or create a
-    color from the pallette.
+    color from the palette.
   * Out of slice - if this box is checked, `out of slice` is on or true. If this
     box is not checked, `out of slice` is off or false. If it is on or true,
     vectors slightly out of slice are rendered.

docs/howtos/perfmon.md

@@ -146,7 +146,7 @@ Create a minimal perfmon config file `/tmp/perfmon.json` that looks like this:
 ```
 
 This will write `/tmp/latest.json` every time we run napari. This file is
-only written on exit, and you must exit with the **Quit** commmand. Using
+only written on exit, and you must exit with the **Quit** command. Using
 `trace_file_on_start` is often easier than manually starting a trace using
 the **Debug** menu.
 

docs/naps/3-spaces.md

@@ -36,11 +36,11 @@ The above workarounds have the following issues:
 - *performance and usability*: regardless of the workaround used, reader plugins can't know about it, so a user would be forced to either first load everything into the viewer and then do something with it, significantly slowing down startup and adding one more step to opening napari
 - *serialization*: without a native `napari` support, these workarounds cannot be properly serialized.
 
-Additionally, while this was not the main goal of this NAP, people have sometimes asked for "workspaces", where different workflows can be tested in parallel [^workspaces]; `spaces` would also implicitly allow this by letting users re-use a layer in multiple spaces.
+Additionally, while this was not the main goal of this NAP, people have sometimes asked for "workspaces", where different workflows can be tested in parallel [^workspaces]; `spaces` would also implicitly allow this by letting users reuse a layer in multiple spaces.
 
 ### Non-goals
 
-- *window state*: in [#4227](https://github.com/napari/napari/issues/4227), a proposal was advanced for managing window state and layout, with the ability to re-use and restore them. While this could be conceivably be dealt with here, it is probably better to keep separate the state of the window from the representation and the data.
+- *window state*: in [#4227](https://github.com/napari/napari/issues/4227), a proposal was advanced for managing window state and layout, with the ability to reuse and restore them. While this could be conceivably be dealt with here, it is probably better to keep separate the state of the window from the representation and the data.
 - *rendering/data separation*: while necessary for some of the future benefits of spaces (i.e: [](nap-3:multicanvas)), the separation of rendering and data from the currently unified `Layer` object is not in the scope of this NAP. This means that (just like now), layer won't be shareable between `Viewer`s. However, they should be shareable between `Space`s, as long as the spaces are not *rendered* at the same time (i.e: in separate `Viewer`s).
 
 ## Implementation proposal
@@ -149,7 +149,7 @@ As part of the "multiple viewers" proposals in the past, the idea of accessing t
 (nap-3:multicanvas)=
 ### Multicanvas
 
-While multicanvas is still some ways off, this NAP can provide the basis for that functionality. For example, a future multicanvas-capable viewer could associate each `Canvas` to a `Space`; this way, we already have the machinery for multiple layer lists, as well as the ability to re-use the same layer in multiple canvases, while having a different `Camera` and `Dims` setup for the different copies (note that this would rely on the current efforts in separating the slicing logic from the `Layer` object).
+While multicanvas is still some ways off, this NAP can provide the basis for that functionality. For example, a future multicanvas-capable viewer could associate each `Canvas` to a `Space`; this way, we already have the machinery for multiple layer lists, as well as the ability to reuse the same layer in multiple canvases, while having a different `Camera` and `Dims` setup for the different copies (note that this would rely on the current efforts in separating the slicing logic from the `Layer` object).
 
 
 ## References

docs/naps/4-async-slicing.md

@@ -62,7 +62,7 @@ often causes issues for developers.
 Some of these issues were caused by a previous effort around asynchronous slicing
 in an effort to keep it isolated from the core code base.
 By contrast, our approach in this project is to redesign slicing in napari to
-provide a solid foundation for asychronous slicing and related future work like
+provide a solid foundation for asynchronous slicing and related future work like
 multi-canvas and multi-scale slicing.
 
 ### Goals