TODOs.md: spellchecking

1 files changed, 4 insertions, 4 deletions

diff --git a/TODOs.md b/TODOs.md
index 7c347cc..fc945d3 100644
--- a/TODOs.md
+++ b/TODOs.md
@@ -40,7 +40,7 @@ Options:
 
   I've considered this, and I even started working on it, but I've chosen not to pursue it further, as I now think this is a mistake.
 
-  Regardless of gettext's power and usefulness, it is definitvely an overkill for for this application.
+  Regardless of gettext's power and usefulness, it is definitely an overkill for for this application.
   It would bring more things to the project, both in build time (requiring the generation of message files and friends) but also in run time (loading the message files themselves).
   This could certainly be done via `$PREFIX/libexec/$lang.sh` or something equivalent, but this would also be increasing the installation complexity, too.
   Expecting a sane installation environment is sane (but not always true), but the reasoning behind doing is just "because".
@@ -51,9 +51,9 @@ Options:
 
   For the modest purpose of this software, the current solution is good enough.
   Maybe it could be less restrictive of country or encoding, but the fundamental idea of embedded variables with an `eval` to define the relevant one stays the same.
-  Changing from an `eval` to a `case` statement builds upon the same underlying principle: of having string variables on the same file, and keep them in sync in a completly manual process.
+  Changing from an `eval` to a `case` statement builds upon the same underlying principle: of having string variables on the same file, and keep them in sync in a completely manual process.
 
-  Consider the cost and complexity of building tooling around the [quotation of the `don't` text][quotation], and one can envision one of the challenges that including in specialized i18n tooling might bring along.
+  Consider the cost and complexity of building tooling around the [quotation of the `don't` text][quotation], and one can envision one of the challenges that including in specialised i18n tooling might bring along.
   Those tools have their usages and places, they do exist for a good reason, and they should be used when applicable, but this is not it.
 
   This isn't really about POSIX sh, implementation language, or even the size of the program, but about the trade-off analysis of this use case, where I'm the one writing the code and the translations on a tiny piece of POSIX sh code.
@@ -261,7 +261,7 @@ This is an anti-pattern in the viewpoint of the category of files that should ex
 
 Since gettext itself isn't standard (see [discussion] on this topic), adding this requirement to the consumer (user of packager) isn't desirable.
 
-So here I'm optimizing for more things being commited in the repository in the name of less requirements.
+So here I'm optimising for more things being commited in the repository in the name of less requirements.
 
 [discussion]: https://www.austingroupbugs.net/view.php?id=1122