diff --git a/authors/archie.mdx b/authors/archie.mdx
index b64acf16..b4504c22 100644
--- a/authors/archie.mdx
+++ b/authors/archie.mdx
@@ -4,7 +4,7 @@ avatar: /static/avatars/archie.png
 occupation: CEO
 company: General Translation
 email: archie@generaltranslation.com
-twitter: https://x.com/archiemckenzie_/photo
+twitter: https://x.com/archiemckenzie_
 linkedin: https://www.linkedin.com/in/archie-mckenzie
 ---
 
diff --git a/authors/jackie.mdx b/authors/jackie.mdx
index 2ac16548..c99d0722 100644
--- a/authors/jackie.mdx
+++ b/authors/jackie.mdx
@@ -1,6 +1,7 @@
 ---
 name: Jackie Chen
 avatar: /static/avatars/jackie.png
+occupation: Software Engineer
 company: General Translation
 email: jackie@generaltranslation.com
 twitter: https://x.com/Some_Jackie
diff --git a/blog/en-US/ai-chatbot.mdx b/blog/en-US/ai-chatbot.mdx
index b9a59f0f..829e9c8d 100644
--- a/blog/en-US/ai-chatbot.mdx
+++ b/blog/en-US/ai-chatbot.mdx
@@ -200,7 +200,7 @@ const gt = useGT();
 
 That was it! All of the text in the chatbot was now internationalized and available in any language.
 
-## Deploying to Production
+## Deploying to production
 
 Deploying to production was even easier. I swapped out my `GT_API_KEY` environment variable with a production API key and ran the translate command:
 
diff --git a/blog/en-US/gt-next.mdx b/blog/en-US/gt-next.mdx
index 4f30479e..ec639cc5 100644
--- a/blog/en-US/gt-next.mdx
+++ b/blog/en-US/gt-next.mdx
@@ -40,9 +40,9 @@ The goal with gt-next is to create an abundance mindset around translations. The
 - Get an API key 🔐 on our [platform](https://generaltranslation.com)
 - Read the [docs](https://generaltranslation.com/docs) 📄
 
-### What you can do with gt-next
+## What you can do with gt-next
 
-#### Format variables and plurals
+### Format variables and plurals
 
 ```javascript copy
 import { T } from 'gt-next'
@@ -67,7 +67,7 @@ export default function Page() {
 }
 ```
 
-#### Use a developer API key to see translations locally
+### Use a developer API key to see translations locally
 
 ```.env copy
 GT_API_KEY="gtx-dev-cae62d6fe1e33bda603c9a2926ab0fb8"
diff --git a/devlog/en-US/compiler_v1_0_0_gt-next_v6_7_0.mdx b/devlog/en-US/compiler_v1_0_0_gt-next_v6_7_0.mdx
index cc484436..d83484e9 100644
--- a/devlog/en-US/compiler_v1_0_0_gt-next_v6_7_0.mdx
+++ b/devlog/en-US/compiler_v1_0_0_gt-next_v6_7_0.mdx
@@ -9,7 +9,7 @@ tags: ['@general-translation/compiler', 'v1.0.0', 'compiler', 'translation', 'i1
 
 We are very excited to announce the release of @general-translation/compiler v1.0.0.
 
-As we stated in our `gt-next@6.2.0` release, we believe the future of i18n libraries lies in build-time processing. Earlier this year, we released a SWC plugin for `gt-next` that enabled optimizations like compile-time hashing and better dev-time string translations. While this provided an excellent (albeit intense) introduction to compiler plugins for our team, its scope was limited to Next.js projects only.
+As we stated in our `gt-next@6.2.0` release, we believe the future of i18n libraries lies in build-time processing. Earlier this year, we released an SWC plugin for `gt-next` that enabled optimizations like compile-time hashing and better dev-time string translations. While this provided an excellent (albeit intense) introduction to compiler plugins for our team, its scope was limited to Next.js projects only.
 
 We're following through on our commitment to build-time processing by releasing this general-purpose React compiler plugin. This means all the build-time optimizations from `gt-next` are now available to every `gt-react` user!
 
diff --git a/devlog/en-US/gt-i18n_v0_1_0.mdx b/devlog/en-US/gt-i18n_v0_1_0.mdx
index 528ab2a2..06fe79d1 100644
--- a/devlog/en-US/gt-i18n_v0_1_0.mdx
+++ b/devlog/en-US/gt-i18n_v0_1_0.mdx
@@ -14,13 +14,13 @@ Though `generaltranslation` is also a runtime-agnostic library, it is—by desig
 
 ---
 
-## What's Included
+## What's included
 
 - **[`msg()`](#)** - String registration and variable interpolation
 - **[`mFallback()`](#)** and **[`gtFallback()`](#)** - Migration helpers for incremental adoption
 
 ---
 
-## Looking Forward
+## Looking forward
 
 This library is still very much in its infancy, but expect to see more string-related i18n functionality in the future.
\ No newline at end of file
diff --git a/devlog/en-US/gt-next_v6_10_0.mdx b/devlog/en-US/gt-next_v6_10_0.mdx
index 4cc7d094..2891dbd9 100644
--- a/devlog/en-US/gt-next_v6_10_0.mdx
+++ b/devlog/en-US/gt-next_v6_10_0.mdx
@@ -14,7 +14,7 @@ tags: ['gt-next', 'v6.10.0', 'cached components', 'SSG', 'static site generation
 
 ---
 
-## Cached Components
+## Cached components
 
 To enable cached component support, add `experimentalLocaleResolution: true` to your gt-next configuration and follow [the Next.js Cache Components guide](https://nextjs.org/docs/app/getting-started/cache-components). When using cached components with translatable content, you must pass the `locale` as a parameter to ensure proper cache invalidation across different locales.
 
@@ -48,13 +48,13 @@ export default async function Home() {
 
 ### The `locale` parameter requirement
 
-Cached components use their parameters as cache keys, any cached component that contains translatable content must accept a `locale` parameter if they are to update when a user's locale changes. For example, `CachedContent` must accept a `locale` parameter to create separate cache entries for each locale. Without this parameter, the component would serve the same cached content regardless of the user's locale.
+Cached components use their parameters as cache keys. Any cached component that contains translatable content must accept a `locale` parameter if they are to update when a user's locale changes. For example, `CachedContent` must accept a `locale` parameter to create separate cache entries for each locale. Without this parameter, the component would serve the same cached content regardless of the user's locale.
 
 ### Configuration notes
 
 When `experimentalLocaleResolution` is enabled:
 - I18n proxy must be enabled for locale resolution to work (see [I18n Proxy](/docs/next/guides/middleware))
-- It overrides any custom `getLocale` functions (locale resolution happens from the reading the URL path)
+- It overrides any custom `getLocale` functions (locale resolution happens from reading the URL path)
 - It disables `getRegion` and `getDomain` functions
 - It conflicts with the deprecated `experimentalEnableSSG` configuration - only one can be enabled at a time
 - You can customize the locale parameter name with `experimentalLocaleResolutionParam` (defaults to `'locale'`)
@@ -69,7 +69,7 @@ export default withGTConfig(nextConfig, {
 
 ---
 
-## Deprecating Legacy Static Request Functions
+## Deprecating legacy static request functions
 
 Following the introduction of static rendering support in gt-next@6.9, we are now deprecating the legacy static request functions (`getStaticLocale`, `getStaticRegion`, `getStaticDomain`) in favor of the standard request functions (`getLocale`, `getRegion`, `getDomain`). 
 
@@ -77,7 +77,7 @@ This deprecation aligns with our goal of simplifying the API surface while maint
 
 ---
 
-## Migration Guide
+## Migration guide
 
 ### Legacy SSG
 
@@ -111,7 +111,7 @@ export default async function getRegion() {
 }
 ```
 
-### For Cached Components
+### For cached components
 
 Enable experimental locale resolution and ensure cached components receive locale parameters:
 
diff --git a/devlog/en-US/gt-next_v6_11_0.mdx b/devlog/en-US/gt-next_v6_11_0.mdx
index 872e014e..44da34b4 100644
--- a/devlog/en-US/gt-next_v6_11_0.mdx
+++ b/devlog/en-US/gt-next_v6_11_0.mdx
@@ -20,7 +20,7 @@ gt('Welcome to our application', { $maxChars: 20 });
 // AI attempts translation within 20 chars: "Bienvenido a app"
 ```
 
-### Character Limit Handling
+### Character limit handling
 
 The `$maxChars` parameter triggers two distinct mechanisms:
 
diff --git a/devlog/en-US/gt-next_v6_12_0.mdx b/devlog/en-US/gt-next_v6_12_0.mdx
index 505f0da5..0ff5ddb9 100644
--- a/devlog/en-US/gt-next_v6_12_0.mdx
+++ b/devlog/en-US/gt-next_v6_12_0.mdx
@@ -15,7 +15,7 @@ Like with JSX, many applications rely heavily on string construction through uti
 **gt-next 6.12.0** bridges this gap by introducing `declareStatic()` - the string equivalent of the `<Static>` component - along with supporting functions `declareVar()` and `decodeVars()`.
 
 
-## Core Functionality
+## Core functionality
 
 ### `declareStatic()`
 
@@ -51,9 +51,9 @@ const decodedGreeting = decodeVars(greeting);
 // "Hello, Brian"
 ```
 
-## Additional Improvements
+## Additional improvements
 
-### Enhanced String Functions
+### Enhanced string functions
 
 Both `gt()` and `msg()` now support string concatenation for **static strings** only:
 
@@ -62,7 +62,7 @@ gt("Hello " + "world");
 msg("Welcome, " + "Brian");
 ```
 
-### Expanded `<Static>` Support
+### Expanded `<Static>` support
 
 Up until this point, the `<Static>` component only supported function invocations as children.
 Now, it can support arbitrary JSX expressions resolvable at build time such as nested JSX text, ternary operators, conditional statements, and function calls.
@@ -82,7 +82,7 @@ function getDisplayName(name) {
 </T>
 ```
 
-## Performance Considerations
+## Performance considerations
 
 Like `<Static>`, `declareStatic()` multiplies translation entries.
 Each function call with multiple outcomes creates separate translations, and multiple `declareStatic()` calls in the same string multiply the total entries exponentially.
diff --git a/devlog/en-US/gt-next_v6_2_0.mdx b/devlog/en-US/gt-next_v6_2_0.mdx
index 44172874..cb59d56a 100644
--- a/devlog/en-US/gt-next_v6_2_0.mdx
+++ b/devlog/en-US/gt-next_v6_2_0.mdx
@@ -18,14 +18,14 @@ To keep things focused, we started small with three key improvements.
 
 ---
 
-## Compile-Time Hashing
+## Compile-time hashing
 
 While a relatively small optimization, we now perform **hash calculations at build time** instead of at runtime.  
 Functions like `getGT()` and server-side `<T>` no longer need to compute and cache hashes on every call, resulting in more consistent performance.
 
 ---
 
-## Translation on Demand
+## Translation on demand
 
 One of the biggest pain points for developers has been refreshing the page during development to see real-time string updates.
 
@@ -48,15 +48,15 @@ export default function Page() {
 We deliberately kept `gt()` synchronous to match other i18n libraries.
 The downside was a `two-step translation process`:
 
-    1.	Register the text with the API.
-    2.	Wait for a second render to display the translated result.
+1. Register the text with the API.
+2. Wait for a second render to display the translated result.
 
 Now, thanks to the compiler, translatable content is scanned ahead of time and passed directly into `useGT()` or `getGT()` at compile time.
 This means translations are immediately available at runtime — no page refreshes.
 
 ---
 
-## Build-Time Linting
+## Build-time linting
 
 Previously, detecting incorrect usage of `<T>` components required running `gtx-cli` with a custom linter.
 This created inconsistencies between **development** and **production** behavior.
diff --git a/devlog/en-US/gt-next_v6_8_0.mdx b/devlog/en-US/gt-next_v6_8_0.mdx
index a074c54a..922d214c 100644
--- a/devlog/en-US/gt-next_v6_8_0.mdx
+++ b/devlog/en-US/gt-next_v6_8_0.mdx
@@ -59,7 +59,7 @@ function Component({ gender, toy }) {
 }
 ```
 
-## Important Considerations
+## Important considerations
 
 That being said, we strongly emphasize using the `<Static>` component carefully and judiciously.
 The `<Static>` component, while powerful, can also lead to major increases in the number of translation entries.
@@ -87,7 +87,7 @@ function Component({ gender }) {
 }
 ```
 
-## Limitations and Future Improvements
+## Limitations and future improvements
 
 ### Multiplication
 
diff --git a/devlog/en-US/gt-next_v6_9_0.mdx b/devlog/en-US/gt-next_v6_9_0.mdx
index 6018dc8d..f7d553b2 100644
--- a/devlog/en-US/gt-next_v6_9_0.mdx
+++ b/devlog/en-US/gt-next_v6_9_0.mdx
@@ -13,7 +13,7 @@ Static rendering is a core competency of the Next.js framework, delivering pre-r
 Given this, any Next.js-native library should work seamlessly within this rendering model.
 **gt-next 6.9.0** introduces static rendering support, allowing internationalized applications to leverage Next.js's full static generation capabilities without compromising on locale detection or translation functionality.
 
-## What is Static Rendering?
+## What is static rendering?
 
 Static rendering generates HTML at build time rather than on each request.
 While this approach delivers exceptional performance, it presents challenges for i18n libraries that typically rely on request headers, cookies, or middleware to determine user locale.
@@ -21,13 +21,13 @@ During static rendering, these request-time dependencies are unavailable, requir
 
 ---
 
-## Static Rendering Setup
+## Static rendering setup
 
 Before configuring gt-next, ensure your Next.js application is set up for static generation by following the [generateStaticParams documentation](https://nextjs.org/docs/app/api-reference/functions/generate-static-params).
 
 The setup involves three key components:
 
-### 1. Enable Static Rendering in Configuration
+### 1. Enable static rendering in configuration
 
 ```js
 export default withGTConfig(nextConfig, {
@@ -35,7 +35,7 @@ export default withGTConfig(nextConfig, {
 })
 ```
 
-### 2. Configure Middleware
+### 2. Configure middleware
 
 Set up middleware for dynamic requests:
 
@@ -52,7 +52,7 @@ export const config = {
 }
 ```
 
-### 3. Define Static Locale Detection
+### 3. Define static locale detection
 
 Create a `getStaticLocale` function that determines locale during static rendering. This function only runs during static generation - during SSR, the default behavior (reading headers, cookies, etc.) is used.
 
@@ -86,7 +86,7 @@ export default async function getStaticLocale() {
 
 ---
 
-## Additional Features
+## Additional features
 
 Beyond static generation, this release also introduces support for custom `getLocale()` and `getRegion()` functions that can be configured for both SSR and static rendering environments.
 
diff --git a/devlog/en-US/gt-node_v0_2_0.mdx b/devlog/en-US/gt-node_v0_2_0.mdx
index 544ad1bd..908a9e33 100644
--- a/devlog/en-US/gt-node_v0_2_0.mdx
+++ b/devlog/en-US/gt-node_v0_2_0.mdx
@@ -21,7 +21,7 @@ This mirrors the API in our other libraries like `gt-next` when working with asy
 
 ---
 
-## What's Included
+## What's included
 
 - **`initializeGT()`** — Configures the i18n singleton. Call once at server startup.
 - **`withGT(locale, fn)`** — Wraps a request handler to scope the locale. All translation calls inside the callback use the provided locale. All routes must be wrapped in `withGT`.
@@ -84,7 +84,7 @@ That's it. Strings are picked up by the GT compiler at build time, translated du
 
 ---
 
-## Looking Forward
+## Looking forward
 
 `gt-node` and `gt-tanstack-start` are the first two libraries built on the `gt-i18n` singleton architecture. Expect more framework adapters to follow the same pattern.
 
diff --git a/devlog/en-US/gt-node_v0_3_0.mdx b/devlog/en-US/gt-node_v0_3_0.mdx
index 665a93ba..d13f941b 100644
--- a/devlog/en-US/gt-node_v0_3_0.mdx
+++ b/devlog/en-US/gt-node_v0_3_0.mdx
@@ -11,7 +11,7 @@ tags: ['gt-node', 'v0.3.0', 'node', 'locale', 'helpers', 'i18n']
 
 These already existed in `gt-next` and `gt-react`. Adding them to `gt-node` brings server-side parity so you can access locale information without reaching into the i18n manager directly.
 
-## What's New
+## What's new
 
 ### `getLocale()`
 
diff --git a/devlog/en-US/gt-react_v10_8_0.mdx b/devlog/en-US/gt-react_v10_8_0.mdx
index 9c051c7b..b7cc1b51 100644
--- a/devlog/en-US/gt-react_v10_8_0.mdx
+++ b/devlog/en-US/gt-react_v10_8_0.mdx
@@ -11,7 +11,7 @@ In **gt-react 10.8.0**, we've added feature flag support through the `enableI18n
 
 ---
 
-## Synchronous Behavior
+## Synchronous behavior
 
 When `enableI18n` is set to `false`, i18n functionality is disabled by:
 - Setting the locale list to only the default locale
@@ -25,7 +25,7 @@ When `enableI18n` is set to `false`, i18n functionality is disabled by:
 
 ---
 
-## Asynchronous Behavior
+## Asynchronous behavior
 
 For dynamic feature flags, use `enableI18nLoaded` to indicate loading state:
 
@@ -46,7 +46,7 @@ During loading, the library checks the `generaltranslation.enable-i18n` cookie t
 
 ---
 
-## SSG/SSR Considerations
+## SSG/SSR considerations
 
 With SSG, the first render cycle is sacrificed when the default `enableI18n` value is `false`, as static generation cannot determine the runtime feature flag state.
 
diff --git a/devlog/en-US/gt-tanstack-start_v0_1_0.mdx b/devlog/en-US/gt-tanstack-start_v0_1_0.mdx
index 3e1a11e4..9f2429f7 100644
--- a/devlog/en-US/gt-tanstack-start_v0_1_0.mdx
+++ b/devlog/en-US/gt-tanstack-start_v0_1_0.mdx
@@ -13,7 +13,7 @@ tags: ['gt-tanstack-start', 'v0.1.0', 'tanstack-start', 'tanstack', 'i18n', 'tra
 
 ---
 
-## What's Included
+## What's included
 
 - **`initializeGT()`** — Configures the i18n manager for TanStack Start. Call this once at the top of your root route file.
 - **`GTProvider`** — Wraps your app with translation context, with built-in SSR detection and locale resolution tailored to TanStack Start.
@@ -45,14 +45,14 @@ npm install gt-tanstack-start
 }
 ```
 
-### Set Environment Variables
+### Set environment variables
 
 ```env
 VITE_GT_PROJECT_ID=your-project-id
 VITE_GT_DEV_API_KEY=your-dev-api-key
 ```
 
-### Create a Translation Loader
+### Create a translation loader
 
 ```ts
 // loadTranslations.ts
@@ -62,7 +62,7 @@ export async function loadTranslations(locale: string) {
 }
 ```
 
-### Set Up Your Root Route
+### Set up your root route
 
 ```tsx
 // __root.tsx
@@ -109,7 +109,7 @@ function RootDocument({ children }: { children: React.ReactNode }) {
 }
 ```
 
-### Translate Content
+### Translate content
 
 ```tsx
 import { T } from 'gt-tanstack-start';
@@ -125,7 +125,7 @@ export default function Page() {
 
 ---
 
-## Looking Forward
+## Looking forward
 
 This is v0.1.0 — the foundation is here, but there's plenty more to build.
 SSG and locale routing are some of the next features we are looking to add in upcoming releases.
diff --git a/devlog/en-US/gtx-cli_v2_3_0.mdx b/devlog/en-US/gtx-cli_v2_3_0.mdx
index 83d9ee2f..68d4751a 100644
--- a/devlog/en-US/gtx-cli_v2_3_0.mdx
+++ b/devlog/en-US/gtx-cli_v2_3_0.mdx
@@ -60,7 +60,7 @@ Creating 12 translation(s)
 your/file/path.mdx [es]
 ```
 
-With this change, we can now guarantee that your translations will generate even in the off chance setup fails.
+With this change, we can now guarantee that your translations will generate even on the off chance that setup fails.
 
 We also like that it gives you more visibility into how and where we generate the content that influences your translations, and it makes adding new setup steps worry-free since they will never stop translation from happening.
 
diff --git a/devlog/en-US/local-edits.mdx b/devlog/en-US/local-edits.mdx
index 8115996e..5cbabe89 100644
--- a/devlog/en-US/local-edits.mdx
+++ b/devlog/en-US/local-edits.mdx
@@ -12,7 +12,7 @@ This means you can now make translation changes locally, persist them, and keep
 
 ---
 
-## The `save-local` Command
+## The `save-local` command
 
 Historically, the only way to make translation edits was through the dashboard editor. That worked, but it often broke flow, especially if you were mid-development and just wanted to tweak a translation inline.
 
@@ -26,7 +26,7 @@ Running this command uploads any modified translation files, merges your local c
 
 ---
 
-## Translate (Now With Local Awareness)
+## Translate (now with local awareness)
 
 Until now, `translate` would always assume the remote version of a translation was the source of truth.
 
@@ -55,7 +55,7 @@ Files to translate:
 
 ---
 
-## What Happens When Sources Change
+## What happens when sources change
 
 You might wonder: _what if I edit the source file after making local translation edits?_  
 In earlier versions, that would have triggered a full retranslation that wiped your custom changes.
diff --git a/devlog/en-US/react-core-linter_v0_1_0.mdx b/devlog/en-US/react-core-linter_v0_1_0.mdx
index 22baaa2c..c9fc6f2b 100644
--- a/devlog/en-US/react-core-linter_v0_1_0.mdx
+++ b/devlog/en-US/react-core-linter_v0_1_0.mdx
@@ -28,7 +28,7 @@ Two rules are included in this initial release:
 
 ---
 
-## Static JSX Validation
+## Static JSX validation
 
 The `static-jsx` rule prevents dynamic content from appearing directly inside `<T>` components.
 Dynamic content must be wrapped in [variable components](/docs/react/guides/variables).
@@ -43,7 +43,7 @@ Dynamic content must be wrapped in [variable components](/docs/react/guides/vari
 
 ---
 
-## Static String Enforcement
+## Static string enforcement
 
 The `static-string` rule ensures translation functions only accept non-changing strings.
 
diff --git a/docs/en-US/cli/faqs.mdx b/docs/en-US/cli/faqs.mdx
index 32e9381b..18d25431 100644
--- a/docs/en-US/cli/faqs.mdx
+++ b/docs/en-US/cli/faqs.mdx
@@ -3,22 +3,22 @@ title: FAQs
 description: Frequently asked questions about the GT CLI tool
 ---
 
-### Do I need an API key to use the CLI?
+## Do I need an API key to use the CLI?
 
 The [`translate`](/docs/cli/translate) command requires a production API key, which you can get for free at [generaltranslation.com](https://generaltranslation.com). The [`init`](/docs/cli/init) command can generate one for you during setup.
 
-### When should I run `gt translate`?
+## When should I run `gt translate`?
 
 Run it in your CI/CD pipeline **before** building your app for production. It should not be used during development — in development, use development API keys for on-demand translation instead.
 
-### Can I use the CLI with libraries other than gt-next and gt-react?
+## Can I use the CLI with libraries other than gt-next and gt-react?
 
 Yes. The CLI can generate translations for third-party i18n libraries like [next-intl](https://next-intl.dev/) and [i18next](https://react.i18next.com/). It can also translate standalone JSON, Markdown, MDX, JS, and TS files.
 
-### What file formats does the CLI support?
+## What file formats does the CLI support?
 
 The CLI supports [JSON](/docs/cli/formats/json), [MDX](/docs/cli/formats/mdx), [HTML](/docs/cli/formats/html), [TypeScript/JavaScript](/docs/cli/formats/ts), [YAML](/docs/cli/formats/yaml), [PO/POT](/docs/cli/formats/po), [plain text](/docs/cli/formats/txt), and [GT's internal format](/docs/cli/formats/gt).
 
-### Where do the translations go?
+## Where do the translations go?
 
 Depending on your configuration, translations are either uploaded to the GT CDN or saved locally in your project bundle. See [`save-local`](/docs/cli/save-local) for details on storing translations locally.
diff --git a/docs/en-US/cli/stage.mdx b/docs/en-US/cli/stage.mdx
index 133e996d..bc54f157 100644
--- a/docs/en-US/cli/stage.mdx
+++ b/docs/en-US/cli/stage.mdx
@@ -71,10 +71,10 @@ There are a few key parameters:
 
 | Parameter       | Description                                      |
 |-----------------|--------------------------------------------------|
-| `--dry-run` | This flag will cause the CLI to parse and validate your project, but will not communicate with the GT API. This is useful for validating your codebase.
-| `--api-key` | Unless you are using `--dry-run`, you must provide a production API key.
-| `--project-id` | Similarly, unless you are using `--dry-run`, you must provide a project ID.
-| `--new, --locales <locales>` | Locales to translate your project into. These will be appended to the locales specified in your `gt.config.json` file.
+| `--dry-run` | This flag will cause the CLI to parse and validate your project, but will not communicate with the GT API. This is useful for validating your codebase. |
+| `--api-key` | Unless you are using `--dry-run`, you must provide a production API key. |
+| `--project-id` | Similarly, unless you are using `--dry-run`, you must provide a project ID. |
+| `--new, --locales <locales>` | Locales to translate your project into. These will be appended to the locales specified in your `gt.config.json` file. |
 
 ### Configuration file
 
diff --git a/docs/en-US/core/class/constructor.mdx b/docs/en-US/core/class/constructor.mdx
index 6dd23740..85f14101 100644
--- a/docs/en-US/core/class/constructor.mdx
+++ b/docs/en-US/core/class/constructor.mdx
@@ -80,7 +80,7 @@ const gt = new GT({
 
 ### With custom locale mapping
 A custom mapping can be provided.
-This lets the user (1) use aliases for locale codes which, (2) can override the standard BCP 47 validation, and (3) override the standard BCP 47 locale information.
+This lets the user (1) use aliases for locale codes, (2) override the standard BCP 47 validation, and (3) override the standard BCP 47 locale information.
 
 For example, say you wanted to use `cn` as an alias for `zh`.
 Because the General Translation API does not support `cn`, you must specify a custom mapping.
diff --git a/docs/en-US/core/class/methods/formatting/format-date-time.mdx b/docs/en-US/core/class/methods/formatting/format-date-time.mdx
index 4f35d391..11f94976 100644
--- a/docs/en-US/core/class/methods/formatting/format-date-time.mdx
+++ b/docs/en-US/core/class/methods/formatting/format-date-time.mdx
@@ -157,3 +157,6 @@ console.log(gt.formatDateTime(date, {
 
 ## Next steps
 
+- Use standalone [`formatDateTime`](/docs/core/functions/formatting/format-date-time) for usage without a GT instance
+- Format messages with [`formatMessage`](/docs/core/class/methods/formatting/format-message)
+
diff --git a/docs/en-US/core/class/methods/formatting/format-message.mdx b/docs/en-US/core/class/methods/formatting/format-message.mdx
index 6076b3ac..e3133380 100644
--- a/docs/en-US/core/class/methods/formatting/format-message.mdx
+++ b/docs/en-US/core/class/methods/formatting/format-message.mdx
@@ -6,7 +6,7 @@ description: API reference for the GT formatMessage method
 ## Overview
 
 The `formatMessage` method formats messages with variable substitution and locale-aware formatting.
-Built on top of Format.JS's [`intl-messageformat`](https://formatjs.github.io/docs/intl-messageformat/) library, it supports ICU message format patterns.
+Built on top of FormatJS's [`intl-messageformat`](https://formatjs.github.io/docs/intl-messageformat/) library, it supports ICU message format patterns.
 
 This method is essential for variable interpolation and pluralization.
 It also supports number formatting and date formatting among other features.
@@ -153,7 +153,7 @@ const orderStatusMessage = gt.formatMessage(`
 
 ## Notes
 
-- The method processes ICU message format syntax for advanced formatting using [`Intl.MessageFormat`](https://formatjs.github.io/docs/intl-messageformat/) from Format.JS.
+- The method processes ICU message format syntax for advanced formatting using [`Intl.MessageFormat`](https://formatjs.github.io/docs/intl-messageformat/) from FormatJS.
 - Missing variables will throw an error.
 - Locale-specific number, date, and currency formatting is applied automatically
 
diff --git a/docs/en-US/core/functions/formatting/format-message.mdx b/docs/en-US/core/functions/formatting/format-message.mdx
index 4334d54e..09b1645c 100644
--- a/docs/en-US/core/functions/formatting/format-message.mdx
+++ b/docs/en-US/core/functions/formatting/format-message.mdx
@@ -5,8 +5,8 @@ description: API reference for the standalone formatMessage function
 
 ## Overview
 
-The `formatMessage` method formats messages with variable substitution and locale-aware formatting.
-Built on top of Format.JS's [`intl-messageformat`](https://formatjs.github.io/docs/intl-messageformat/) library, it supports ICU message format patterns.
+The standalone `formatMessage` function formats messages with variable substitution and locale-aware formatting without requiring a GT instance.
+Built on top of FormatJS's [`intl-messageformat`](https://formatjs.github.io/docs/intl-messageformat/) library, it supports ICU message format patterns.
 
 This method is essential for variable interpolation and pluralization.
 It also supports number formatting and date formatting among other features.
diff --git a/docs/en-US/core/locales.mdx b/docs/en-US/core/locales.mdx
index 284ad8ef..e2cf39ff 100644
--- a/docs/en-US/core/locales.mdx
+++ b/docs/en-US/core/locales.mdx
@@ -42,7 +42,7 @@ Together, `zh-Hant-HK` means "Chinese, written in traditional characters, as spo
 See the [list of supported locales](/docs/platform/supported-locales) for a searchable list of all locales currently supported by General Translation.
 
 Technically, the library supports any validly constructed tag, including private use codes with no widely recognized meaning. 
-However, the platform will only translate
+However, the platform will only translate into locales it currently supports.
 
 ### Equivalent locale tags
 
@@ -79,6 +79,6 @@ since translating between them is impossible.
 
 ### Next steps
 
-- See our [List of Supported Locales](/docs/platform/supported-locales) to find the language tags available in General Translation.
+- See our [list of supported locales](/docs/platform/supported-locales) to find the language tags available in General Translation.
 - Refer to the official [IETF Language Tag Registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)
   and the [BCP 47 Language Tag standard](https://www.techonthenet.com/js/language_tags.php) for more information.
diff --git a/docs/en-US/core/quickstart.mdx b/docs/en-US/core/quickstart.mdx
index 6abc8693..818d4ba2 100644
--- a/docs/en-US/core/quickstart.mdx
+++ b/docs/en-US/core/quickstart.mdx
@@ -21,7 +21,7 @@ We will cover string translation and file translation.
     This is completely free, and will give you access to the translation services.
 
 
-    Navigate to the [`API Keys` page](https://dash.generaltranslation.com/api-keys) click `Create API Key`.
+    Navigate to the [`API Keys` page](https://dash.generaltranslation.com/api-keys) and click `Create API Key`.
     Choose a name for your API key, and click `Create`.
 
     ![API key page](https://assets.gtx.dev/core/quickstart/core-quickstart-1.png)
@@ -96,9 +96,9 @@ In order to translate a file, you need to follow these four steps:
 4. Download the translated file.
 
 <Callout type='info'>
-  #### Why not just one call? Typically, people will want to translate many
-  files at once. By breaking these into four clear steps, it gives users much
-  more flexibility in how they can use the API.
+  #### Why not just one call?
+
+  Typically, people will want to translate many files at once. By breaking these into four clear steps, it gives users much more flexibility in how they can use the API.
 </Callout>
 
 <Steps>
@@ -106,7 +106,7 @@ In order to translate a file, you need to follow these four steps:
     ### 1. Upload the file
 
     Uploading files returns a list of file references with the [`uploadSourceFiles`](/docs/core/class/methods/translation/upload-source-files) method.
-    This allows you to later check the enqueue the file for translation, check the status of the file, and download the translated file.
+    This allows you to later enqueue the file for translation, check the status of the file, and download the translated file.
 
     ```typescript title="src/index.ts"
     import fs from 'fs';
diff --git a/docs/en-US/key-concepts/dynamic-content.mdx b/docs/en-US/key-concepts/dynamic-content.mdx
index 55fbabc2..0ab3bbf9 100644
--- a/docs/en-US/key-concepts/dynamic-content.mdx
+++ b/docs/en-US/key-concepts/dynamic-content.mdx
@@ -101,7 +101,7 @@ By wrapping private information in a `<Var>` component, you can ensure that the
 <Callout>
     **Exceptions**
 
-    The exceptions to the statement above are (1) in the case of a nested `<T>` component used inside of a `<Var>` component (ie, the children of the nested `<T>` component will be translated)
+    The exceptions to the statement above are (1) in the case of a nested `<T>` component used inside of a `<Var>` component (i.e., the children of the nested `<T>` component will be translated)
     or (2) when data is passed intentionally to our API via some other means within a child of the `<Var>` component (i.e., a fetch call).
     However, this is not the intended use of the `<Var>` component nor the General Translation API and doing so can harm load times and performance.
 
diff --git a/docs/en-US/locadex/mintlify.mdx b/docs/en-US/locadex/mintlify.mdx
index 09fba0e9..c9b50a14 100644
--- a/docs/en-US/locadex/mintlify.mdx
+++ b/docs/en-US/locadex/mintlify.mdx
@@ -75,7 +75,7 @@ After the initial setup PR is merged, Locadex monitors your main branch for comm
 
 ### Supported frameworks
 
-Currently, Locadex only supports Mintlify and [Next.js App router](/docs/locadex) apps.
+Currently, Locadex only supports Mintlify and [Next.js App Router](/docs/locadex) apps.
 
 ### Troubleshooting
 
diff --git a/docs/en-US/next/api/components/tx.mdx b/docs/en-US/next/api/components/tx.mdx
index 9e8c23ad..3e3b5c2c 100644
--- a/docs/en-US/next/api/components/tx.mdx
+++ b/docs/en-US/next/api/components/tx.mdx
@@ -71,7 +71,7 @@ This means translation will be performed live.
 
 `<Tx>` translates jsx at runtime.
 This means that translations are performed live, so you can translate content that is only known at runtime.
-The trade off is that there is a delay while waiting for an on-demand translation to load is significantly slower.
+The trade off is that there is a delay while waiting for an on-demand translation to load, which is significantly slower.
 
 While loading, `<Tx>` will return undefined unless languages are similar (en-US vs en-GB), though this behavior can be customized with render settings.
 If an error occurs, `<Tx>` will return the original content.
diff --git a/docs/en-US/next/api/config/with-gt-config.mdx b/docs/en-US/next/api/config/with-gt-config.mdx
index e04c0465..f5d63c05 100644
--- a/docs/en-US/next/api/config/with-gt-config.mdx
+++ b/docs/en-US/next/api/config/with-gt-config.mdx
@@ -24,7 +24,7 @@ export default withGTConfig(nextConfig, {
 **Legacy**
 
 `initGT` is the legacy way to configure the `gt-next` library. It returns a function callback which is then called on the `NextConfig` object.
-The props for both functions are the same, with the exception that `withGTProps` requires `NextConfig` to also be passed in.
+The props for both functions are the same, with the exception that `withGTConfig` requires `NextConfig` to also be passed in.
 </Callout>
 
 Use `withGTConfig` to:
@@ -217,7 +217,7 @@ If the translation is cached, response time is too low to justify loading behavi
 Timeouts only apply to runtime translations, or translations that need to be performed on demand as they have not been cached.
 
 Timeouts are set to 8 seconds by default.
-This design decision is to facilitate vercel users who have a default 10-second timeout for serverless functions on the free plan.
+This design decision is to facilitate Vercel users who have a default 10-second timeout for serverless functions on the free plan.
 
 ---
 
diff --git a/docs/en-US/next/api/strings/get-gt.mdx b/docs/en-US/next/api/strings/get-gt.mdx
index b4b12ac4..fad386b7 100644
--- a/docs/en-US/next/api/strings/get-gt.mdx
+++ b/docs/en-US/next/api/strings/get-gt.mdx
@@ -47,7 +47,7 @@ This ensures fast load times for all locales, but it can only translate content
 
 Once generated, translations are either (1) stored in the CDN or (2) stored in your app's build output, according to your configuration.
 From there, the translated content is served to your users.
-If a translation is not found, it will fallback to the original content.
+If a translation is not found, it will fall back to the original content.
 
 Make sure to follow the [deployment guide here](/docs/next/tutorials/quickdeploy).
 
@@ -148,7 +148,7 @@ export default async function TranslateGreeting() {
 
 ## Notes
  * The `getGT` function is a server-side function that translates strings.
- * Translations strings with `getGT` happen before runtime, during the build process (unless in development).
+ * Translating strings with `getGT` happens before runtime, during the build process (unless in development).
 
 ## Next steps
  * See [`useGT`](/docs/next/api/strings/use-gt) for client-side string translations at buildtime.
diff --git a/docs/en-US/next/api/strings/get-messages.mdx b/docs/en-US/next/api/strings/get-messages.mdx
index d4355fe0..299ab276 100644
--- a/docs/en-US/next/api/strings/get-messages.mdx
+++ b/docs/en-US/next/api/strings/get-messages.mdx
@@ -47,7 +47,7 @@ This ensures fast load times for all locales, but it can only translate content
 
 Once generated, translations are either (1) stored in the CDN or (2) stored in your app's build output, according to your configuration.
 From there, the translated content is served to your users.
-If a translation is not found, it will fallback to the original content.
+If a translation is not found, it will fall back to the original content.
 
 Make sure to follow the [deployment guide here](/docs/next/tutorials/quickdeploy).
 
@@ -152,7 +152,7 @@ export default async function TranslateGreeting() {
 
 ## Notes
  * The `getMessages` function is a server-side function that translates encoded strings from `msg`.
- * Translations strings with `getMessages` happen before runtime, during the build process (unless in development).
+ * Translating strings with `getMessages` happens before runtime, during the build process (unless in development).
 
 ## Next steps
  * See [`useMessages`](/docs/next/api/strings/use-messages) for client-side string translations from encoded strings at buildtime.
diff --git a/docs/en-US/next/api/strings/tx.mdx b/docs/en-US/next/api/strings/tx.mdx
index 2f00e28d..df372e52 100644
--- a/docs/en-US/next/api/strings/tx.mdx
+++ b/docs/en-US/next/api/strings/tx.mdx
@@ -52,9 +52,9 @@ A promise that resolves to a string containing the translated content, or the or
 
 The `tx` function translates strings at runtime.
 This means that translations are performed live, so you can translate content that is only known at runtime.
-The trade off is that there is a delay while waiting for an on-demand translation to load is significantly slower.
+The trade off is that there is a delay while waiting for an on-demand translation to load.
 
-Our advice is to translate everything you can at build time using [`getGT`](/docs/next/api/strings/use-gt), [`useGT`](/docs/next/api/strings/use-gt), or [`<T>`](/docs/next/api/components/t),
+Our advice is to translate everything you can at build time using [`getGT`](/docs/next/api/strings/get-gt), [`useGT`](/docs/next/api/strings/use-gt), or [`<T>`](/docs/next/api/components/t),
 and only use on-demand translations, like `tx` and [`<Tx>`](/docs/next/api/components/tx), when necessary.
 
 Make sure to follow the [deployment guide here](/docs/next/tutorials/quickdeploy).
diff --git a/docs/en-US/next/api/types/dictionary-translation-options.mdx b/docs/en-US/next/api/types/dictionary-translation-options.mdx
index 97d8336c..ecf76893 100644
--- a/docs/en-US/next/api/types/dictionary-translation-options.mdx
+++ b/docs/en-US/next/api/types/dictionary-translation-options.mdx
@@ -110,7 +110,7 @@ const Component = () => {
 ## Notes
  * Variables are passed as top-level keys in the options object, not nested under a `variables` key.
 
-### Next steps
+## Next steps
  * See [dictionaries](/docs/next/guides/dictionaries) for more information on dictionaries and common practices.
  * See [`useTranslations`](/docs/next/api/dictionary/use-translations) or [`getTranslations`](/docs/next/api/dictionary/get-translations) for more information on dictionaries interface.
  * See [`ICU message format`](https://unicode-org.github.io/icu/userguide/format_parse/messages/) for more information on formatting options.
diff --git a/docs/en-US/next/concepts/environments.mdx b/docs/en-US/next/concepts/environments.mdx
index 921fc34f..135c3308 100644
--- a/docs/en-US/next/concepts/environments.mdx
+++ b/docs/en-US/next/concepts/environments.mdx
@@ -52,7 +52,7 @@ When rendering a component (that uses `useGT`, `<T>`, or `useTranslations`) in a
 1. If it detects a valid, stored translation for the given content, it will render the translation.
 2. If no translation is found, it will attempt to dynamically translate the content via the General Translation API.
 3. After translating, the translation will be rendered, and stored in memory for future use.
-4. If the translation times out, it will fallback and render the original content.
+4. If the translation times out, it will fall back and render the original content.
 
 <Callout type="info">
   Our API also internally caches development translations for a short period of time, so if the same translation is requested again, it will be served from cache.
diff --git a/docs/en-US/next/guides/migration.mdx b/docs/en-US/next/guides/migration.mdx
index a7af6c92..1502c145 100644
--- a/docs/en-US/next/guides/migration.mdx
+++ b/docs/en-US/next/guides/migration.mdx
@@ -104,7 +104,7 @@ You'll never have to wait for translations again.
 
     1. Fully migrate your entire project to `gt-next`, and remove the old i18n library.
     2. Fully migrate your project, but keep using dictionaries from the old i18n library.
-    2. Keep using the old i18n library for now, and only migrate part of your project to `gt-next`.
+    3. Keep using the old i18n library for now, and only migrate part of your project to `gt-next`.
 
     For more details on each option, see the [migration strategies](#strategies) section.
   </Step>
@@ -221,7 +221,7 @@ We offer it as a way to make migration easier, but we don't recommend using it f
 
 ### 3. Using AI
 
-If you are using AI to help you migrate your project, we have a `LLMs.txt` and `LLMs-full.txt` available at:
+If you are using AI to help you migrate your project, we have an `LLMs.txt` and `LLMs-full.txt` available at:
 
 - [LLMs.txt](/llms.txt)
 - [LLMs-full.txt](/llms-full.txt)
diff --git a/docs/en-US/next/tutorials/examples/currency-converter/preptx.mdx b/docs/en-US/next/tutorials/examples/currency-converter/preptx.mdx
index 37819bbc..a8a7acd2 100644
--- a/docs/en-US/next/tutorials/examples/currency-converter/preptx.mdx
+++ b/docs/en-US/next/tutorials/examples/currency-converter/preptx.mdx
@@ -19,7 +19,7 @@ npm i gt-next
 ```
 
 ### Set up your environment
-Create a `.env` file in the root of your project and add your api key and project id.
+Create a `.env` file in the root of your project and add your API key and project ID.
 
 ```dotenv copy
 GT_API_KEY="YOUR_GT_API_KEY"
diff --git a/docs/en-US/next/tutorials/examples/next-speedrun.mdx b/docs/en-US/next/tutorials/examples/next-speedrun.mdx
index 315d130a..d528af56 100644
--- a/docs/en-US/next/tutorials/examples/next-speedrun.mdx
+++ b/docs/en-US/next/tutorials/examples/next-speedrun.mdx
@@ -42,7 +42,7 @@ npm i gt
 ## Step 3: Add your environment variables.
 
 Navigate to the [Dashboard](https://generaltranslation.com/en-US/signin).
-Go to the Dev Api Keys page on the nav bar and create a new API key and Project ID.
+Go to the Dev API Keys page on the nav bar and create a new API key and Project ID.
 Then add them to your `.env` file.
 
 ```bash copy
@@ -116,7 +116,7 @@ If you have set up everything correctly, you should see your app in the language
         **Browser Cookies**
 
         Check your browser's cookies for your app.
-        General translation uses cookies to store the user's language preference.
+        General Translation uses cookies to store the user's language preference.
         The cookie is called `generaltranslation.locale`, and all you need to do is delete it.
         It will be under `localhost:3000`.
         Then, just double-check you are using the desired preferred language and then
@@ -135,7 +135,7 @@ If you have set up everything correctly, you should see your app in the language
 ---
 
 ## Notes
- * Translate arbitrary jsx with the `<T>` component.
+ * Translate arbitrary JSX with the `<T>` component.
  * If translation is not working when you change your language, check your browser's cookies.
 
 ## Next steps
diff --git a/docs/en-US/node/api/strings/msg.mdx b/docs/en-US/node/api/strings/msg.mdx
index 88c5fb32..733be947 100644
--- a/docs/en-US/node/api/strings/msg.mdx
+++ b/docs/en-US/node/api/strings/msg.mdx
@@ -132,7 +132,7 @@ console.log(translated);
 
 ## Notes
  * The `msg` function is a function that marks strings for translation.
- * Translations strings with `msg` happen before runtime, during the build process (unless in development).
+ * Translating strings with `msg` happens before runtime, during the build process (unless in development).
 
 ## Next steps
  * See [`getMessages`](/docs/node/api/get-messages) for resolving translated strings at runtime.
diff --git a/docs/en-US/node/guides/strings.mdx b/docs/en-US/node/guides/strings.mdx
index 877797ae..bf586cc9 100644
--- a/docs/en-US/node/guides/strings.mdx
+++ b/docs/en-US/node/guides/strings.mdx
@@ -1,6 +1,6 @@
 ---
 title: String Translation Patterns
-description: Two approaches to translating strings in Node.js — inline and pre-registered
+description: Three approaches to translating strings in Node.js — inline, pre-registered, and on-demand
 ---
 
 There are three ways to translate strings in `gt-node`:
@@ -96,7 +96,7 @@ app.post('/api/translate', async (req, res) => {
 | `tx()` | Dynamic or user-generated content not known at build time |
 
 <Callout>
-  Both approaches produce identical translations. The difference is only in code organization — pick whichever fits your project structure.
+  `getGT()` and `msg()`/`getMessages()` produce identical translations — the difference is only in code organization. Use `tx()` only when content isn't known at build time.
 </Callout>
 
 ## Using `$context` for disambiguation
diff --git a/docs/en-US/react-native/api/components/gtprovider.mdx b/docs/en-US/react-native/api/components/gtprovider.mdx
index e73d5d80..885616c9 100644
--- a/docs/en-US/react-native/api/components/gtprovider.mdx
+++ b/docs/en-US/react-native/api/components/gtprovider.mdx
@@ -212,7 +212,7 @@ export default function App() {
 
 ### Render settings
 
-Render settings controls the loading behavior for translations.
+Render settings control the loading behavior for translations.
 There are two fields: `timeout` and `method`.
 
 - `timeout` is the number of milliseconds to wait for a translation to load before showing a fallback (default: `8000ms`).
@@ -234,7 +234,7 @@ In this case, it will return the fallback content immediately until the translat
 
 ## Notes
 
-- The `<GTProvider>` must wrap all [`<T>` components](/docs/react-native/api/components/t) and other translation-related functions. Learn more [here](/docs/react-native/api/components/gtprovider).
+- The `<GTProvider>` must wrap all [`<T>` components](/docs/react-native/api/components/t) and other translation-related functions.
 
 ## Next steps
 
diff --git a/docs/en-US/react-native/api/helpers/get-locale-from-native-store.mdx b/docs/en-US/react-native/api/helpers/get-locale-from-native-store.mdx
index b82b8a73..f5406d74 100644
--- a/docs/en-US/react-native/api/helpers/get-locale-from-native-store.mdx
+++ b/docs/en-US/react-native/api/helpers/get-locale-from-native-store.mdx
@@ -16,7 +16,7 @@ const locale = getLocaleFromNativeStore(key?);
 
 | Parameter | Type | Description |
 |-----------|------|-------------|
-| `key` | `string?` | The storage key to read from. Defaults to `'generaltranslation.locale'`. If your [`<GTProvider>`](/docs/react-native/api/components/gtprovider) uses a custom `localeCookieName`, pass that same value here. |
+| `key` | `string?` | The storage key to read from. Defaults to `'generaltranslation.locale'`. If your [`<GTProvider>`](/docs/react-native/api/components/gtprovider) uses a custom storage key, pass that same value here. |
 
 ### Returns
 
@@ -32,7 +32,7 @@ import { getLocaleFromNativeStore } from 'gt-react-native';
 const locale = getLocaleFromNativeStore();
 ```
 
-If your `GTProvider` uses a custom `localeCookieName`, pass the same key:
+If your `GTProvider` uses a custom storage key, pass the same key:
 
 ```jsx copy
 const locale = getLocaleFromNativeStore('my-custom-key');
diff --git a/docs/en-US/react/api/components/gtprovider.mdx b/docs/en-US/react/api/components/gtprovider.mdx
index 65c8d604..72b9472f 100644
--- a/docs/en-US/react/api/components/gtprovider.mdx
+++ b/docs/en-US/react/api/components/gtprovider.mdx
@@ -216,7 +216,7 @@ createRoot(document.getElementById("root")!).render(
 
 ### Render settings
 
-Render settings controls the loading behavior for translations.
+Render settings control the loading behavior for translations.
 There are two fields: `timeout` and `method`.
 
 - `timeout` is the number of milliseconds to wait for a translation to load before showing a fallback (default: `8000ms`).
@@ -238,7 +238,7 @@ In this case, it will return the fallback content immediately until the translat
 
 ## Notes
 
-- The `<GTProvider>` must wrap all [`<T>` components](/docs/react/api/components/t) and other translation-related functions. Learn more [here](/docs/react/api/components/gtprovider).
+- The `<GTProvider>` must wrap all [`<T>` components](/docs/react/api/components/t) and other translation-related functions.
 
 ## Next steps
 
diff --git a/docs/en-US/sanity/guides/serialization.mdx b/docs/en-US/sanity/guides/serialization.mdx
index 17e1632a..f5a4421a 100644
--- a/docs/en-US/sanity/guides/serialization.mdx
+++ b/docs/en-US/sanity/guides/serialization.mdx
@@ -9,7 +9,7 @@ The plugin converts Sanity documents to HTML for translation, then deserializes
 
 ## How serialization works
 
-1. **Serialize**: `gt-sanity` converts document to HTML
+1. **Serialize**: `gt-sanity` converts the document to HTML
 2. **Translate**: HTML is sent to the General Translation API for translation. Content is re-arranged and re-formatted for the target locale.
 3. **Deserialize**: `gt-sanity` parses translated HTML and merges it with the original document