Merge pull request #3608 from aMiss-aWry/typofix-1

Minor typo fixes in documentation

docs/source/Components/FuncParser.md

@@ -20,7 +20,7 @@ To escape the inlinefunc (e.g. to explain to someone how it works, use `$$`)
 You say "To get a random value from 1 to 5, use $randint(1,5)."
 ```
 
-While `randint` may look and work just like `random.randint` from the standard Python library, it is _not_. Instead it's a `inlinefunc` named `randint` made available to Evennia (which in turn uses the standard library function). For security reasons, only functions explicitly assigned to be used as inlinefuncs are viable. 
+While `randint` may look and work just like `random.randint` from the standard Python library, it is _not_. Instead it's an `inlinefunc` named `randint` made available to Evennia (which in turn uses the standard library function). For security reasons, only functions explicitly assigned to be used as inlinefuncs are viable. 
 
 You can apply the `FuncParser`  manually. The parser is initialized with the inlinefunc(s) it's supposed to recognize in that string. Below is an example of a parser only understanding a single `$pow` inlinefunc: 
 
@@ -84,7 +84,7 @@ parser = FuncParser(["game.myfuncparser_callables", "game.more_funcparser_callab
 
 Here, `callables` points to a collection of normal Python functions (see next section) for you to make
 available to the parser as you parse strings with it. It can either be
-- A `dict` of `{"functionname": callable, ...}`. This allows you do pick and choose exactly which callables
+- A `dict` of `{"functionname": callable, ...}`. This allows you to pick and choose exactly which callables
   to include and how they should be named. Do you want a callable to be available under more than one name?
   Just add it multiple times to the dict, with a different key.
 - A `module` or (more commonly) a `python-path` to a module. This module can define a dict
@@ -235,7 +235,7 @@ everything but the outermost double quotes.
 
 Since you don't know in which order users may use your callables, they should
 always check the types of its inputs and convert to the type the callable needs.
-Note also that when converting from strings, there are limits what inputs you
+Note also that when converting from strings, there are limits on what inputs you
 can support. This is because FunctionParser strings can be used by
 non-developer players/builders and some things (such as complex
 classes/callables etc) are just not safe/possible to convert from string

docs/source/Components/Typeclasses.md

@@ -244,18 +244,18 @@ The arguments to this method are described [in the API docs here](github:evennia
 
 Technically, typeclasses are [Django proxy models](https://docs.djangoproject.com/en/4.1/topics/db/models/#proxy-models).  The only database models that are "real" in the typeclass system (that is, are represented by actual tables in the database) are `AccountDB`, `ObjectDB`, `ScriptDB` and `ChannelDB` (there are also [Attributes](./Attributes.md) and [Tags](./Tags.md) but they are not typeclasses themselves). All the subclasses of them are "proxies", extending them with Python code without actually modifying the database layout.
 
-Evennia modifies Django's proxy model in various ways to allow them to work without any boiler plate (for example you don't need to set the Django "proxy" property in the model `Meta` subclass, Evennia handles this for you using metaclasses). Evennia also makes sure you can query subclasses as well as patches django to allow multiple inheritance from the same base class.
+Evennia modifies Django's proxy model in various ways to allow them to work without any boiler plate (for example you don't need to set the Django "proxy" property in the model `Meta` subclass, Evennia handles this for you using metaclasses). Evennia also makes sure you can query subclasses as well as patches Django to allow multiple inheritance from the same base class.
 
 ### Caveats
 
-Evennia uses the *idmapper* to cache its typeclasses (Django proxy models) in memory. The idmapper allows things like on-object handlers and properties to be stored on typeclass instances and to not get lost as long as the server is running (they will only be cleared on a Server reload). Django does not work like this by default; by default every time you search for an object in the database you'll get a *different* instance of that object back and anything you stored on it that was not in the database would be lost. The bottom line is that Evennia's Typeclass instances subside in memory a lot longer than vanilla Django model instance do. 
+Evennia uses the *idmapper* to cache its typeclasses (Django proxy models) in memory. The idmapper allows things like on-object handlers and properties to be stored on typeclass instances and to not get lost as long as the server is running (they will only be cleared on a Server reload). Django does not work like this by default; by default every time you search for an object in the database you'll get a *different* instance of that object back and anything you stored on it that was not in the database would be lost. The bottom line is that Evennia's Typeclass instances subsist in memory a lot longer than vanilla Django model instances do. 
 
 There is one caveat to consider with this, and that relates to [making your own models](New-
 Models): Foreign relationships to typeclasses are cached by Django and that means that if you were to change an object in a foreign relationship via some other means than via that relationship, the object seeing the relationship may not reliably update but will still see its old cached version. Due to typeclasses staying so long in memory, stale caches of such relationships could be more visible than common in Django. See the [closed issue #1098 and its comments](https://github.com/evennia/evennia/issues/1098) for examples and solutions.
 
 ## Will I run out of dbrefs? 
 
-Evennia does not re-use its `#dbrefs`. This means new objects get an ever-increasing `#dbref`, also if you delete older objects. There are technical and safety reasons for this. But you may wonder if this means you have to worry about a big game 'running out' of dbref integers eventually.
+Evennia does not re-use its `#dbrefs`. This means new objects get an ever-increasing `#dbref`, even if you delete older objects. There are technical and safety reasons for this. But you may wonder if this means you have to worry about a big game 'running out' of dbref integers eventually.
 
 The answer is simply **no**.