feat: spell checking with typos (#305)

.github/workflows/spellcheck.yml

@@ -0,0 +1,19 @@
+name: "Spell check"
+
+on:
+  - push
+  - pull_request
+
+jobs:
+  check:
+    # run on all push events or on PR syncs not from the same repo
+    if: github.event_name != 'pull_request' || github.repository != github.event.pull_request.head.repo.full_name
+
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+      - name: Spell check
+        uses: crate-ci/[email protected]
+        with:
+          config: ./.typos.toml

.typos.toml

@@ -0,0 +1,67 @@
+[files]
+extend-exclude = ["docs/versioned"] # don't check ./docs/versioned
+
+[default]
+locale = "en-us"
+
+[default.extend-identifiers]
+FilterThreshhold = "FilterThreshhold" # ignore error, it is actually "Paper.FilterThreshhold" in Paper
+
+[default.extend-words]
+accessorise = "accessorize"
+aluminium = "aluminum"
+analyse = "analyze"
+armour = "armor"
+authorise = "authorize"
+authorised = "authorized"
+authorising = "authorizing"
+catalogue = "catalog"
+centre = "center"
+civilisation = "civilization"
+civilised = "civilized"
+colour = "color"
+colours = "colors"
+defence = "defense"
+gramme = "gram"
+grammes = "grams"
+grey = "gray"
+honour = "honor"
+honours = "honors"
+kerb = "curb"
+kerbs = "curbs"
+labour = "labor"
+licence = "license"
+licences = "licenses"
+manoeuvre = "maneuver"
+manoeuvres = "maneuvers"
+metre = "meter"
+metres = "meters"
+modelled = "modeled"
+neighbour = "neighbor"
+neighbours = "neighbors"
+neighbouring = "neighboring"
+organisation = "organization"
+organise = "organize"
+organised = "organized"
+organising = "organizing"
+practise = "practice"
+practised = "practiced"
+practising = "practicing"
+recognise = "recognize"
+recognised = "recognized"
+recognising = "recognizing"
+routeing = "routing"
+serialise = "serialize"
+serialiser = "serializer"
+serialising = "serializing"
+deserialise = "deserialize"
+deserialiser = "deserializer"
+deserialising = "deserializing"
+tonne = "ton"
+tonnes = "tons"
+traveller = "traveler"
+travelling = "traveling"
+regionise = "regionize"
+regioniser = "regionizer"
+regionising = "regionizing"
+regionised = "regionized"

config-specs/paper/paper-world-defaults.yml

@@ -888,7 +888,7 @@ misc:
 
       **Note:** Both the Eigencraft and Alternate Current implementations change
       the behavior of redstone dust. You can read about how behavior is changed
-      in each implementation's respective documention:
+      in each implementation's respective documentation:
 
       - Eigencraft: No official documentation available. However,
       [theosib's comments](https://bugs.mojang.com/browse/MC-81098?focusedCommentId=420777#comment-420777)

config-specs/paper/server-properties.yml

@@ -101,7 +101,7 @@ level-type:
 max-chained-neighbor-updates:
   default: '1000000'
   description: >
-    Limits the number of consecutive neighbour updates before skipping subsequent updates. Negative
+    Limits the number of consecutive neighbor updates before skipping subsequent updates. Negative
     values will disable the limit.
 max-players:
   default: '20'
@@ -174,7 +174,7 @@ resource-pack-prompt:
 resource-pack-sha1:
   default: ''
   description: >
-    The hash of the resource pack, used for verification. This is reccomended to be set to ensure
+    The hash of the resource pack, used for verification. This is recommended to be set to ensure
     players are downloading the correct pack.
 server-ip:
   default: ''

docs/folia/admin/reference/overview.md

@@ -16,12 +16,12 @@ operations, and then inter region operations.
 
 In order to ensure that regions are independent, the rules for
 maintaining regions must ensure that a ticking region
-has no directly adjacent neighbour regions which are ticking.
+has no directly adjacent neighbor regions which are ticking.
 The following rules guarantee the invariant is upheld:
 1. Any ticking region may not grow while it is ticking.
 2. Any ticking region must initially own a small buffer of chunks outside
    its perimeter.
-3. Regions may not _begin_ to tick if they have a neighbouring adjacent
+3. Regions may not _begin_ to tick if they have a neighboring adjacent
    region.
 4. Adjacent regions must eventually merge to form a single region.
 

docs/folia/admin/reference/region-logic.md

@@ -4,7 +4,7 @@ title: Region Logic
 description: An overview to how Folia's regionizer works.
 ---
 
-## Fundamental regionising logic
+## Fundamental regionizing logic
 
 ## Region
 
@@ -14,21 +14,21 @@ to note that for any non-dead region x, that for each chunk position y
 it owns that there is no other non-dead region z such that
 the region z owns the chunk position y.
 
-## Regioniser
+## Regionizer
 
-Each world has its own regioniser. The regioniser is a term used 
-to describe the logic that the class "ThreadedRegioniser" executes 
+Each world has its own regionizer. The regionizer is a term used 
+to describe the logic that the class "ThreadedRegionizer" executes 
 to create, maintain, and destroy regions. Maintenance of regions is 
 done by merging nearby regions together, marking which regions 
 are eligible to be ticked, and finally by splitting any regions 
 into smaller independent regions. Effectively, it is the logic 
 performed to ensure that groups of nearby chunks are considered 
 a single independent region.
 
-## Guarantees the regioniser provides
+## Guarantees the regionizer provides
 
-The regioniser provides a set of important invariants that allows
-regions to tick in parallel without race condtions:
+The regionizer provides a set of important invariants that allows
+regions to tick in parallel without race conditions:
 
 ### First invariant
 
@@ -53,15 +53,15 @@ over non-owned nearby chunks, to ensure that they truly tick
 in parallel, no matter what chunk loads they may issue while
 ticking. 
 
-To comply with the first invariant, the regioniser will 
+To comply with the first invariant, the regionizer will 
 create "transient" regions _around_ ticking regions. Specifically, 
 around in this context means close enough that would require a merge, 
 but not far enough to be considered independent. The transient regions
 created in these cases will be merged into the ticking region 
 when the ticking region finishes ticking.
 
 Both of the second invariant and third invariant combined allow 
-the regioniser to guarantee that a ticking region may create
+the regionizer to guarantee that a ticking region may create
 and then access chunk holders around it (i.e sync loading) without
 the possibility that it steps on another region's toes.
 
@@ -75,18 +75,18 @@ while the "transient" state is used as a state for a region that may
 not tick. The "dead" state is used to mark regions which should
 not be use.
 
-The states transistions are explained later, as it ties in
-with the regioniser's merge and split logic.
+The states transitions are explained later, as it ties in
+with the regionizer's merge and split logic.
 
-## Regioniser implementation
+## Regionizer implementation
 
-The regioniser implementation is a description of how
-the class "ThreadedRegioniser" adheres to the four invariants
+The regionizer implementation is a description of how
+the class "ThreadedRegionizer" adheres to the four invariants
 described previously.
 
 ### Splitting the world into sections
 
-The regioniser does not operate on chunk coordinates, but rather
+The regionizer does not operate on chunk coordinates, but rather
 on "region section coordinates." Region section coordinates simply
 represent a grouping of NxN chunks on a grid, where N is some power
 of two. The actual number is left ambiguous, as region section coordinates
@@ -98,20 +98,20 @@ and z in [0, 15]. Another example with N=16, the chunk (17, -5) is
 contained within region section (1, -1). 
 
 Region section coordinates are used only as a performance
-tradeoff in the regioniser, as by approximating chunks to their
+tradeoff in the regionizer, as by approximating chunks to their
 region coordinate allows it to treat NxN chunks as a single
-unit for regionising. This means that regions do not own chunks positions,
+unit for regionizing. This means that regions do not own chunks positions,
 but rather own region section positions. The grouping of NxN chunks 
-allows the regionising logic to be performed only on 
+allows the regionizing logic to be performed only on 
 the creation/destruction of region sections.
 For example with N=16 this means up to NxN-1=255 possible
 less operations in areas such as addChunk/region recalculation 
 assuming region sections are always full.
 
 ### Implementation variables
 
-The implemnetation variables control how aggressively the
-regioniser will maintain regions and merge regions.
+The implementation variables control how aggressively the
+regionizer will maintain regions and merge regions.
 
 #### Recalculation count
 
@@ -136,7 +136,7 @@ The empty section creation radius variable is used to determine
 how many empty region sections are to exist around _any_ 
 region section with at least one chunk. 
 
-Internally, the regioniser enforces the third invariant by
+Internally, the regionizer enforces the third invariant by
 preventing ticking regions from owning new region sections.
 The creation of empty sections around any non-empty section will 
 then enforce the second invariant.
@@ -158,8 +158,8 @@ region coordinate = chunk coordinate >> region section chunk shift.
 
 ### Operation
 
-The regioniser is operated by invoking ThreadedRegioniser#addChunk(x, z) 
-or ThreadedRegioniser#removeChunk(x, z) when a chunk holder is created 
+The regionizer is operated by invoking ThreadedRegionizer#addChunk(x, z) 
+or ThreadedRegionizer#removeChunk(x, z) when a chunk holder is created 
 or destroyed. 
 
 Additionally, ThreadedRegion#tryMarkTicking can be used by a caller
@@ -194,7 +194,7 @@ considered to belong to the region that owns them just as alive sections.
 
 ### Addition of chunks (addChunk)
 
-The addition of chunks to the regioniser boils down to two cases:
+The addition of chunks to the regionizer boils down to two cases:
 
 #### Target region section already exists and is not empty
 

docs/paper/dev/api/plugin-messaging.md

@@ -152,7 +152,7 @@ public class MyPlugin extends JavaPlugin implements PluginMessageListener {
         Player player = ...;
         ByteArrayDataOutput out = ByteStreams.newDataOutput();
         out.writeUTF("Forward");
-        out.writeUTF("ALL"); // This is the target server. "ALL" will message all servers appart from the one sending the message
+        out.writeUTF("ALL"); // This is the target server. "ALL" will message all servers apart from the one sending the message
         out.writeUTF("SecretInternalChannel"); // This is the channel.
 
         ByteArrayOutputStream msgbytes = new ByteArrayOutputStream();

docs/velocity/admin/reference/comparison.md

@@ -83,7 +83,7 @@ exposes, which Velocity cannot perfectly emulate. As a result, the number of cha
 to BungeeCord and have plugins retain the same behavior is minimal.
 
 Suppose you have play a video game published by Company A. It runs on an operating system made by Company B.
-One day, Company B releases a new version of ther operating system, and you upgrade to it, only to recoil
+One day, Company B releases a new version of their operating system, and you upgrade to it, only to recoil
 in horror as that video game no longer works. (Worse, Studio A might be out of business at that point, so
 no patch is forthcoming.) Who do you blame, Company A for producing a defective product, or Company B for
 breaking the game? [This isn't a hypothetical](https://devblogs.microsoft.com/oldnewthing/20110131-00/?p=11633).

docs/velocity/dev/api/command.md

@@ -112,7 +112,7 @@ to also support them. We recommend sticking to the predefined Brigadier types pr
 
 ### `SimpleCommand`
 
-Modelled after the convention popularized by Bukkit and BungeeCord, a `SimpleCommand` has three
+Modeled after the convention popularized by Bukkit and BungeeCord, a `SimpleCommand` has three
 methods: one for when the command is executed, one to provide suggestions for tab completion, and
 one to check a `CommandSource` has permission to use the command. All methods receive a
 `SimpleCommand.Invocation` object, which contains the `CommandSource` that executed the command and

docs/velocity/dev/api/plugin-messaging.md

@@ -141,7 +141,7 @@ public boolean sendPluginMessageToPlayer(Player player, ChannelIdentifier identi
 }
 ```
 
-## BungeeCord Channel Compatability
+## BungeeCord Channel Compatibility
 
 This allows your backend servers to communicate with Velocity
 in a way compatible with BungeeCord