We're French and it's indeed hard for us to get this perfectly right and focusing on the project itself at the same time.
We're planning to move this to github in order to let the community help us on this.
english is the most spoken secondary language.
- They're vs Their and similar normally denote uneducated native English speaker. The code might still be okay, but these typos passing to production makes me check code quality in case some similar QA mistakes are passed in the code.
- Grammar mistakes normally show a foreigner for whom English is not the main language. A small example just in the first line, "to create apps, games that run" => "to create apps and games that run", but this is normally due to a different language constructions. Similar to graphical softwares => graphical software.
So, kudos for OP to write the documentation in a non-native language! (upon light investigation it seems the main writer is French and his coworkers fix typos from time to time).
in germany only grammar nazi's would actually hate such things. they are too common, to say that only uneducated people do it. people who write code and distribute code to the whole world are not writers, there is no need for "perfect" grammar and typos. i mean in my first application i've written quanity instead of quantity (inside the code), somehow it slipped in a lot of places, but i think many many people who will read the code would still understand it. as long as the user interface is checked, i think it's okay if the readme/documentation has typos or grammar mistakes (on open source projects). the most important thing is, is that people understand each other/understand what it's all about. which is just fine for nidium.
- The writer didn't do proofreading (or did it but is not aware of the mistake).
- It's made by a single person with no one else to check on the documentation.
Now while they are not technically a display of low code quality, they are normally indicative of low attention to detail and lonely programming, which is not the optimal situation for high code quality. For people using English as the second language I'm a lot more forgiving since they and their coworkers might not even know how to properly express some things due to translation issues (and not due to lack of proofreading/lonely programming).
In my experience when I'm doing proofreading of my own libraries I also catch ambiguous sentences, lacking documentation or examples and many other things that could be improved upon.