fix: "no one" (#1365)

Fix "no one"

Co-authored-by: Tee Ming <[email protected]>

Author: DePasqualeOrg

apps/svelte.dev/content/blog/2017-09-06-the-zen-of-just-writing-css.md

@@ -17,7 +17,7 @@ This article isn't in any way intended as criticism of the hard work the CSS-in-
 
 Everything in CSS is global. Because of that, styles intended for one bit of markup often end up affecting another. Because of _that_, developers often resort to wild namespacing conventions (not 'rules', since they're very difficult to enforce) that mostly just increase your risk of RSI.
 
-It gets worse when you're working on a team. No-one dares touch styles authored by someone else, because it's often unclear what they're doing, what markup they apply to, and what disasters will unfold if you remove them.
+It gets worse when you're working on a team. No one dares touch styles authored by someone else, because it's often unclear what they're doing, what markup they apply to, and what disasters will unfold if you remove them.
 
 The consequence of all this is the **append-only stylesheet**. There's no way of knowing which code can safely be removed, so it's common to undo some existing style with another, more specific style — even on relatively small projects.
 

apps/svelte.dev/content/blog/2018-12-27-virtual-dom-is-pure-overhead.md

@@ -42,7 +42,7 @@ Misunderstood claims about virtual DOM performance date back to the launch of Re
 	<figcaption>Screenshot from <a href="https://www.youtube.com/watch?v=x7cQ3mrcKaY">Rethinking Best Practices</a> at JSConfEU 2013</figcaption>
 </figure>
 
-But hang on a minute! The virtual DOM operations are _in addition to_ the eventual operations on the real DOM. The only way it could be faster is if we were comparing it to a less efficient framework (there were plenty to go around back in 2013!), or arguing against a straw man — that the alternative is to do something no-one actually does:
+But hang on a minute! The virtual DOM operations are _in addition to_ the eventual operations on the real DOM. The only way it could be faster is if we were comparing it to a less efficient framework (there were plenty to go around back in 2013!), or arguing against a straw man — that the alternative is to do something no one actually does:
 
 ```js
 // @noErrors

apps/svelte.dev/content/blog/2023-03-09-zero-config-type-safety.md

@@ -98,7 +98,7 @@ export type PageData = Kit.ReturnType<
 >;
 ```
 
-We don't actually write `$types.d.ts` into your `src` directory — that would be messy, and no-one likes messy code. Instead, we use a TypeScript feature called [`rootDirs`](https://www.typescriptlang.org/tsconfig#rootDirs), which lets us map ‘virtual’ directories to real ones. By setting `rootDirs` to the project root (the default) and additionally to `.svelte-kit/types` (the output folder of all the generated types) and then mirroring the route structure inside it we get the desired behavior:
+We don't actually write `$types.d.ts` into your `src` directory — that would be messy, and no one likes messy code. Instead, we use a TypeScript feature called [`rootDirs`](https://www.typescriptlang.org/tsconfig#rootDirs), which lets us map ‘virtual’ directories to real ones. By setting `rootDirs` to the project root (the default) and additionally to `.svelte-kit/types` (the output folder of all the generated types) and then mirroring the route structure inside it we get the desired behavior:
 
 ```tree
 // on disk: