Fix small typos in docs (magpylib#669)

* Fix small typos

* retrigger tests

---------

Co-authored-by: Boisselet Alexandre (IFAT DC ATV SC D TE2) <[email protected]>

Author: fspacheco

CONTRIBUTING.md

@@ -1,6 +1,6 @@
 # Contribute
 
-The success of Magpylib relies on its user-friedliness. Your feedback and participation in discussions is strongly encouraged. Ask questions about Magpylib. Tell us what you like and what you dislike. Start general discussions in our informal [Discussions](https://github.com/magpylib/magpylib/discussions) channel on GitHub.
+The success of Magpylib relies on its user-friendliness. Your feedback and participation in discussions is strongly encouraged. Ask questions about Magpylib. Tell us what you like and what you dislike. Start general discussions in our informal [Discussions](https://github.com/magpylib/magpylib/discussions) channel on GitHub.
 
 We use GitHub [Issues and Milestones](https://github.com/magpylib/magpylib/issues) to plan and track the Magpylib project. Open new Issues to report a bug, to point out a problem, or to  make a feature request, e.g. following a fruitful discussion. Within the Issue we will together define in detail what should be done. For small bug fixes, code cleanups, and other small improvements its not necessary to create issues.
 
@@ -23,7 +23,7 @@ You are most welcome to become a project contributor by helping us with coding.
 - All code is well documented and all top level doc strings abide by the [Numpy docstring style](https://numpydoc.readthedocs.io/en/latest/format.html).
 - All unit tests are running. We recommend using the [Pytest](https://docs.pytest.org/en/7.4.x/) package.
 - New unit tests are written aiming for 100% code coverage. We use [Coverage](https://coverage.readthedocs.io/en/) to test this.
-- [Pylint](https://pylint.readthedocs.io/en/stable/) rates your code 10/10 and there are no formatting issues reportet (e.g. line-to-long).
+- [Pylint](https://pylint.readthedocs.io/en/stable/) rates your code 10/10 and there are no formatting issues reported (e.g. line-too-long).
 - Your code is PEP8 compliant and formatted with [Black](https://black.readthedocs.io/en/stable/) default settings.
 
 We strongly suggest that you use the [Pre-Commit](https://pre-commit.com/) hooks that apply important code checks which each commit.

docs/README.md

@@ -1,6 +1,6 @@
 ## About Magpylib Documentation
 
-The Documentation is built with [Sphinx](http://www.sphinx-doc.org/en/main/) v5.3.0. and the configuration file is [conf.py](./conf.py). Files get converted to `.html` files by Sphinx during build time. Images, web code and videos are kept in the [_static](./_static) folder.
+The Documentation is built with [Sphinx](http://www.sphinx-doc.org/en/main/) v5.3.0 and the configuration file is [conf.py](./conf.py). Files get converted to `.html` files by Sphinx during build time. Images, web code and videos are kept in the [_static](./_static) folder.
 
 ### API docs
  The docstring format is under the [Numpy Convention](https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_numpy.html). Sphinx is configured to read Docstring information from the codebase and convert it into pages utilizing the [autodoc extension](http://www.sphinx-doc.org/en/main/usage/extensions/autodoc.html). The generated files are created at build time and put into a folder called `_autogen`

docs/_pages/docu/docu_graphics.md

@@ -90,9 +90,9 @@ objects["Cuboid"].rotate_from_angax(np.linspace(0, 90, 20), "z", anchor=0)
 magpy.show(*objects.values())
 ```
 
-Notice that, objects and their paths are automatically assigned different colors, the magnetization is shown by coloring the poles (default) or by an arrow (via styles). Current directions and dipole objects are indicated by arrows and sensors are shown as tri-colored coordinate cross with pixel as markers.
+Notice that objects and their paths are automatically assigned different colors, the magnetization is shown by coloring the poles (default) or by an arrow (via styles). Current directions and dipole objects are indicated by arrows and sensors are shown as tri-colored coordinate cross with pixel as markers.
 
-How objects are represented graphically (color, line thickness, ect.) is defined by their **style** properties. The default style, which can be seen above, is accessed and manipulated through `magpy.defaults.display.style`. In addition, each object can have an individual style, which takes precedence over the default setting. A local style override is also possible by passing style arguments directly to `show`.
+How objects are represented graphically (color, line thickness, etc.) is defined by their **style** properties. The default style, which can be seen above, is accessed and manipulated through `magpy.defaults.display.style`. In addition, each object can have an individual style, which takes precedence over the default setting. A local style override is also possible by passing style arguments directly to `show`.
 
 The hierarchy that decides about the final graphic object representation, a list of all style parameters and other options for tuning the `show`-output are described in {ref}`examples-graphic-styles` and {ref}`examples-animation`.
 
@@ -451,7 +451,7 @@ magpy.defaults.display.style.magnet.update(
 Any Magpylib object can have its own individual style that will take precedence over the default values when `show` is called. When setting individual styles, the object family specifier such as `magnet` or `current` which is required for the defaults settings, but is implicitly defined by the object type, can be omitted.
 
 ```{warning}
-Users should be aware that specifying individual style attributes massively increases object initializing time (from <50 to 100-500 $\mu$s). There is however the possibility to define styles without affecting the object creation time, but only if the style is defined in the initialization (e.g.: `magpy.magnet.Cuboid(..., style_label="MyCuboid")`). In this case the style attribute creation is deferred to when is is called the first time, typically when calling the `show` function, or accessing the `style` attribute of the object.
+Users should be aware that specifying individual style attributes massively increases object initializing time (from <50 to 100-500 $\mu$s). There is however the possibility to define styles without affecting the object creation time, but only if the style is defined in the initialization (e.g.: `magpy.magnet.Cuboid(..., style_label="MyCuboid")`). In this case the style attribute creation is deferred to when it is called the first time, typically when calling the `show` function, or accessing the `style` attribute of the object.
 While this may not be noticeable for a small number of objects, it is best to avoid setting styles until it is plotting time.
 ```
 
@@ -574,7 +574,7 @@ magpy.show(
 )
 ```
 
-Notice that the sensor, with the shorter path stops before the magnets do. This is an example where {ref}`gallery-tutorial-paths-edge-padding-end-slicing` is applied.
+Notice that the sensor with the shorter path stops before the magnets do. This is an example where {ref}`gallery-tutorial-paths-edge-padding-end-slicing` is applied.
 
 ```{warning}
 Even with some implemented failsafes, such as a maximum frame rate and frame count, there is no guarantee that the animation will be rendered properly. This is particularly relevant when the user tries to animate many objects and/or many path positions at the same time.
@@ -624,7 +624,7 @@ magpy.show(
 
 ### Subplots via context manager `magpylib.show_context`
 
-In order to make the subplot syntax more convenient we introduced the new `show_context` native python context manager. It allows to defer calls to the `show` function while passing additional arguments. This is necessary for Magpylib to now how many rows and columns are been demanded by the user, which single calls to the `show` would not keep track of.
+In order to make the subplot syntax more convenient we introduced the new `show_context` native Python context manager. It allows to defer calls to the `show` function while passing additional arguments. This is necessary for Magpylib to know how many rows and columns are been demanded by the user, which single calls to the `show` would not keep track of.
 
 The above example becomes:
 
@@ -686,8 +686,8 @@ with magpy.show_context():
 +++
 
 In addition the usual 3D models, it is also possible to draw 2D scatter plots of magnetic field data. This is achieved by assigning the `output` argument in the `show` function.
-By default`output='model3d'` displays the 3D representations of the objects. If output is a tuple of strings it must be a combination of 'B' or 'H' and 'x', 'y' and/or 'z'. When having multiple coordinates, the field value is the combined vector length (e.g. `('Bx', 'Hxy', 'Byz')`). `'Bxy'` is equivalent to `sqrt(|Bx|^2 + |By|^2)`. A 2D line plot is then represented accordingly if the objects contain at least one source and one sensor.
-By default source outputs are summed up and sensor pixel, if any, are aggregated by mean (`pixel_agg="mean"`).
+By default `output='model3d'` displays the 3D representations of the objects. If output is a tuple of strings, it must be a combination of 'B' or 'H' and 'x', 'y' and/or 'z'. When having multiple coordinates, the field value is the combined vector length (e.g. `('Bx', 'Hxy', 'Byz')`). `'Bxy'` is equivalent to `sqrt(|Bx|^2 + |By|^2)`. A 2D line plot is then represented accordingly if the objects contain at least one source and one sensor.
+By default source outputs are summed up and sensor pixels, if any, are aggregated by mean (`pixel_agg="mean"`).
 
 ```{code-cell} ipython3
 import magpylib as magpy
@@ -711,12 +711,12 @@ with magpy.show_context(cyl1, cyl2, sensor):
     magpy.show(col=1, output=("Hx", "Hy", "Hz"))
     magpy.show(col=2, output=("Bx", "By", "Bz"))
 
-# display field data with context manager , no sumup
+# display field data with context manager, no sumup
 with magpy.show_context(cyl1, cyl2, sensor):
     magpy.show(col=1, output="Hxy", sumup=False)
     magpy.show(col=2, output="Byz", sumup=False)
 
-# display field data with context manager , no sumup, no pixel_agg
+# display field data with context manager, no sumup, no pixel_agg
 with magpy.show_context(cyl1, cyl2, sensor, sumup=False):
     magpy.show(col=1, output="H", pixel_agg=None)
     magpy.show(col=2, output="B", pixel_agg=None)
@@ -743,7 +743,7 @@ cyl1.position = (4, 0, 0)
 cyl1.rotate_from_angax(angle=np.linspace(0, 300, N), start=0, axis="z", anchor=0)
 cyl2 = cyl1.copy().move((0, 0, 5))
 
-# display field data with context manager , no sumup, no pixel_agg
+# display field data with context manager, no sumup, no pixel_agg
 with magpy.show_context(cyl1, cyl2, sensor, animation=True, style_pixel_size=0.2):
     magpy.show(col=1)
     magpy.show(col=2, output="Bx")
@@ -764,7 +764,7 @@ The input `trace` is a dictionary which includes all necessary information for p
 2. `'constructor'`: name of the plotting constructor from the respective backend, e.g. plotly `'Mesh3d'` or matplotlib `'plot_surface'`
 3. `'args'`: default `None`, positional arguments handed to constructor
 4. `'kwargs'`: default `None`, keyword arguments handed to constructor
-5. `'coordsargs'`: tells magpylib which input corresponds to which coordinate direction, so that geometric representation becomes possible. By default `{'x': 'x', 'y': 'y', 'z': 'z'}` for the `'generic'` backend and Plotly backend,  and `{'x': 'args[0]', 'y': 'args[1]', 'z': 'args[2]'}` for the Matplotlib backend.
+5. `'coordsargs'`: tells Magpylib which input corresponds to which coordinate direction, so that geometric representation becomes possible. By default `{'x': 'x', 'y': 'y', 'z': 'z'}` for the `'generic'` backend and Plotly backend,  and `{'x': 'args[0]', 'y': 'args[1]', 'z': 'args[2]'}` for the Matplotlib backend.
 6. `'show'`: default `True`, toggle if this trace should be displayed
 7. `'scale'`: default 1, object geometric scaling factor
 8. `'updatefunc'`: default `None`, updates the trace parameters when `show` is called. Used to generate  dynamic traces.

docs/_pages/gallery/gallery_tutorial_collection.md

@@ -20,7 +20,7 @@ kernelspec:
 The top level class `Collection` allows users to group objects by reference for common manipulation. The idea is that
 
 1. A collection spans its own local frame of reference with position and orientation, to which the children are added. Thus, any operation applied to the collection is individually applied to all its children.
-2.  The collection itself behaves like a single Magpylib object (can be source and/or observer)
+2. The collection itself behaves like a single Magpylib object (can be source and/or observer).
 3. All children inside the collection can be individually addressed and manipulated at all times.
 4. Collections have their own `style` attributes, their paths are displayed in `show`, and all children are automatically assigned their parent color.
 
@@ -64,7 +64,7 @@ print(f"sensors:     {coll.sensors}")
 print(f"collections: {coll.collections}")
 ```
 
-The **`describe`** method is a very convenient way to view a Collection structure, especially when the collection is nested, i.e. when containing other collections.
+The **`describe`** method is a very convenient way to view a Collection structure, especially when the collection is nested, i.e., when containing other collections.
 
 ```{code-cell} ipython3
 # Add more objects
@@ -104,7 +104,7 @@ print(f"c1.parent:   {c1.parent}")
 print(f"c1.children: {c1.children}")
 ```
 
-Rather than adding objects to a collection, as described above, one can also set the `parent` parameter. A Magpylib object can only have a single parent, i.e. it can only be part of a single collection. As a result, changing the parent will automatically remove the object from it's previous collection.
+Rather than adding objects to a collection, as described above, one can also set the `parent` parameter. A Magpylib object can only have a single parent, i.e., it can only be part of a single collection. As a result, changing the parent will automatically remove the object from its previous collection.
 
 ```{code-cell} ipython3
 import magpylib as magpy
@@ -199,7 +199,7 @@ for coil in [coil1, coil2]:
 magpy.show(*helmholtz, animation=True, style_path_show=False)
 ```
 
-For magnetic field computation a collection with source children behaves like a single source object, and a collection with sensor children behaves like a flat list of it's sensors when provided as `sources` and `observers` input respectively.
+For magnetic field computation, a collection with source children behaves like a single source object, and a collection with sensor children behaves like a flat list of its sensors when provided as `sources` and `observers` input respectively.
 
 ```{code-cell} ipython3
 import matplotlib.pyplot as plt
@@ -218,7 +218,7 @@ plt.show()
 
 ## Efficient 3D Models
 
-The graphical backend libraries were not designed for complex 3D graphic output. As a result, it becomes often inconvenient and slow when attempting to display many 3D objects. One solution to this problem when dealing with large collections, is to represent the latter by a single encompassing body, and to deactivate the individual 3D models of all children.
+The graphical backend libraries were not designed for complex 3D graphic output. As a result, it becomes often inconvenient and slow when attempting to display many 3D objects. One solution to this problem when dealing with large collections is to represent the latter by a single encompassing body, and to deactivate the individual 3D models of all children.
 
 ```{code-cell} ipython3
 import magpylib as magpy

docs/_pages/gallery/gallery_tutorial_field_computation.md

@@ -70,7 +70,7 @@ plt.show()
 
 The `Sensor` class enables relative positioning of observer grids in the global coordinate system. The observer grid is stored in the `pixel` parameter of the sensor object which is `(0,0,0)` by default (sensor position = observer position).
 
-The following example shows a moving and rotating sensor with two pixel. At the same time, the source objects are moving to demonstrate the versatility of the field computation.
+The following example shows a moving and rotating sensor with two pixels. At the same time, the source objects are moving to demonstrate the versatility of the field computation.
 
 ```{code-cell} ipython3
 import numpy as np

docs/_pages/gallery/gallery_tutorial_paths.md

@@ -16,7 +16,7 @@ kernelspec:
 
 # Working with Paths
 
-The position and orientation attributes are key elements of Magpylib. The documentation section {ref}`docu-position` describes how they work. However, these definitions can seem abstract, but the interface was constructed as intuitive as possbile.
+The position and orientation attributes are key elements of Magpylib. The documentation section {ref}`docu-position` describes how they work. However, these definitions can seem abstract, but the interface was constructed as intuitive as possible.
 
 ```{important}
 Always make use of paths when computing with multiple Magpylib object position and orientation instances. This enables vectorized computation. Avoid Python loops at all costs!
@@ -144,9 +144,9 @@ print(sensor.orientation.as_quat())
 
 ## Edge-padding and end-slicing
 
-Magpylib will always make sure that object paths are in the right format, i.e. `position` and `orientation` attributes are of the same length. In addition, when objects with different path lengths are combined, e.g. when computing the field, the shorter paths are treated as static beyond their end to make the computation sensible. Internally, Magpylib follows a philosophy of edge-padding and end-slicing when adjusting paths.
+Magpylib will always make sure that object paths are in the right format, i.e., `position` and `orientation` attributes are of the same length. In addition, when objects with different path lengths are combined, e.g., when computing the field, the shorter paths are treated as static beyond their end to make the computation sensible. Internally, Magpylib follows a philosophy of edge-padding and end-slicing when adjusting paths.
 
-The idea behind **edge-padding** is, that whenever path entries beyond the existing path length are needed the edge-entries of the existing path are returned. This means that the object is considered to be "static" beyond its existing path.
+The idea behind **edge-padding** is that, whenever path entries beyond the existing path length are needed, the edge-entries of the existing path are returned. This means that the object is considered to be "static" beyond its existing path.
 
 In the following example the orientation attribute is padded by its edge value `(0,0,.2)` as the position attribute length is increased.
 
@@ -188,4 +188,4 @@ sensor = Sensor(
 sensor.position=[(1,2,3), (2,3,4)]
 print(sensor.position)
 print(sensor.orientation.as_rotvec())
-```
+```

docs/_pages/reso_news.md

@@ -5,6 +5,6 @@
 ## New Documentation
 **18.08.2023**
 
-- Happy to announce our new, more attractive, more user-fiendly and more complete documentation ! Give us Feedback what you think :). There are still a lot of things to do (specifically in the Example section). Documentation updates coming regularly now.
+- Happy to announce our new, more attractive, more user-friendly and more complete documentation ! Give us Feedback what you think :). There are still a lot of things to do (specifically in the Examples section). Documentation updates coming regularly now.
 
 - It is set up for Magpylib version 4.4 - so some documented features might not be working in 4.3 - release is imminent ! If you cannot wait install from  [main branch](https://github.com/magpylib/magpylib).

docs/index.md

@@ -6,7 +6,7 @@
 
 :::{grid-item}
 :columns: 12
-Magpylib is an **open-source Python package** for calculating static **magnetic fields** of magnets, currents and other sources. It uses **explicit expressions**, solutions to the macroscopic magnetostatic problems, implemented in **vectorized** form which makes the computation **extremely fast**. Make use of the open-source Python ecosystem for spectactular visualization.
+Magpylib is an **open-source Python package** for calculating static **magnetic fields** of magnets, currents and other sources. It uses **explicit expressions**, solutions to the macroscopic magnetostatic problems, implemented in **vectorized** form which makes the computation **extremely fast**. Make use of the open-source Python ecosystem for spectacular visualization.
 :::
 
 :::{grid-item}
@@ -29,7 +29,7 @@ In Magpylib, **sources** (magnets, currents, ...) and **observers** (sensors, po
 :::{grid-item}
 :columns: 12
 <div class="sectiontext">
-<h2>Ressources</h2>
+<h2>Resources</h2>
 </div>
 :::