docs: Fix typos (#1289)

Fixed some typos I found while reading the docs.

docs/pages/docs/design-principles.mdx

@@ -105,7 +105,7 @@ To achieve this, `next-intl` primarly relies on these techniques currently:
 
 Next.js comes with a lot of bells and whistles, but at the same time there are a number of aspects that need to be handled carefully to enable a reliable internationalization integration. `next-intl`, as the name implies, is primarly designed to work well with Next.js. Rather than trying to be a one-size-fits-all solution, `next-intl` integrates with Next.js as deeply as necessary and makes it a priority to stay on top of the latest developments in the Next.js ecosystem.
 
-That being said, `next-intl` has a Next.js-agnostic core that can be used in any React app, or even in plain JavaScript: [`use-intl`](/docs/environments/core-library). This core library contains most features of `next-intl`, but lacks Next.js-specific integrations like routing APIs. The goal of this library is to make it possibly to use familiar APIs in other parts of your stack (e.g. React Native) and, in case you ever feel like Next.js is not the right fit for your project anymore, to provide a straightforward [migration path](#migration-friendly).
+That being said, `next-intl` has a Next.js-agnostic core that can be used in any React app, or even in plain JavaScript: [`use-intl`](/docs/environments/core-library). This core library contains most features of `next-intl`, but lacks Next.js-specific integrations like routing APIs. The goal of this library is to make it possible to use familiar APIs in other parts of your stack (e.g. React Native) and, in case you ever feel like Next.js is not the right fit for your project anymore, to provide a straightforward [migration path](#migration-friendly).
 
 ## Migration-friendly
 
@@ -116,7 +116,7 @@ If you ever feel like Next.js or `next-intl` is not the right fit for your proje
 1. **Moving away from Next.js**: If you decide to migrate away from Next.js, you can continue to use the core library [`use-intl`](/docs/environments/core-library) in any React app, e.g. allowing you to reuse existing components in [a Remix app](/examples#remix).
 2. **Moving away from `next-intl`**: If you find that `next-intl` doesn't fit your needs anymore, you'll have to adapt app code that references the library, but you can still reuse your [standards-based](#standards-based) ICU messages and replace formatting APIs e.g. with direct calls to the [ECMAScript Internationalization API](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl).
 
-We wont hold you back, but if you like, we can stay friends.
+We won't hold you back, but if you like, we can stay friends.
 
 That being said, we're doing our best to make `next-intl` a great fit for your project. If you ever feel like something is not working as expected or if you have ideas for improvements, please let us know on the [issue tracker](https://github.com/amannn/next-intl/issues) and we'll do our best to help you out.
 

docs/pages/docs/environments/error-files.mdx

@@ -164,7 +164,7 @@ export default function Error({error, reset}) {
 }
 ```
 
-Note that `error.tsx` is loaded right after your app has initialized. If your app is performance-senstive and you want to avoid loading translation functionality from `next-intl` as part of this bundle, you can export a lazy reference from your `error` file:
+Note that `error.tsx` is loaded right after your app has initialized. If your app is performance-sensitive and you want to avoid loading translation functionality from `next-intl` as part of this bundle, you can export a lazy reference from your `error` file:
 
 ```tsx filename="error.tsx"
 'use client';

docs/pages/docs/usage/configuration.mdx

@@ -13,7 +13,7 @@ Depending on if you handle [internationalization in Server- or Client Components
 
 ### `i18n.ts` & `getRequestConfig`
 
-`i18n.ts` can be used to provide configuration for **Server Components** via the `getRequestConfig` function and should be set up based on wether you're using [i18n routing](/docs/getting-started/app-router) or not.
+`i18n.ts` can be used to provide configuration for **Server Components** via the `getRequestConfig` function and should be set up based on whether you're using [i18n routing](/docs/getting-started/app-router) or not.
 
 <Tabs items={['With i18n routing', 'Without i18n routing']}>
 

docs/pages/docs/usage/lists.mdx

@@ -29,7 +29,7 @@ function Component() {
 
 See [the MDN docs about `ListFormat`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/ListFormat) to learn more about the options that you can provide to the `list` function or [try the interactive explorer for `Intl.ListFormat`](https://www.intl-explorer.com/ListFormat)).
 
-Note that lists can can currently only be formatted via `useFormatter`, there's no equivalent inline syntax for messages at this point.
+Note that lists can currently only be formatted via `useFormatter`, there's no equivalent inline syntax for messages at this point.
 
 To reuse list formats for multiple components, you can configure [global formats](/docs/usage/configuration#formats).
 

docs/pages/docs/usage/messages.mdx

@@ -314,7 +314,7 @@ Therefore, e.g. when you're mapping a locale to a human readable string, you sho
 
 ```tsx
 const locale = 'en-GB';
-t('message', {locale: locale.replaceAll('-', '_')};
+t('message', {locale: locale.replaceAll('-', '_')});
 ```
 
 </Details>
@@ -437,7 +437,7 @@ Messages are always parsed and therefore e.g. for rich text formatting you need
 
 ```json filename="en.json"
 {
-  "content": "<h1>Headline<h1><p>This is raw HTML</p>"
+  "content": "<h1>Headline</h1><p>This is raw HTML</p>"
 }
 ```