generaltranslation · claude · Jul 5, 2026
@@ -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
 ---
 

@@ -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

@@ -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:
 

@@ -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"

@@ -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!
 

@@ -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.
@@ -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,15 +69,15 @@ 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`). 
 
 This deprecation aligns with our goal of simplifying the API surface while maintaining full functionality. The legacy static functions will continue to work but will emit deprecation warnings. We recommend [migrating to the standard request functions](#migration-guide) for consistency.
 
 ---
 
-## 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:
 

@@ -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:
 

@@ -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.

@@ -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.

@@ -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
 

@@ -13,29 +13,29 @@ 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.
 During static rendering, these request-time dependencies are unavailable, requiring alternative approaches for locale detection.
 
 ---
 
-## 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, {
   experimentalEnableSSG: true,
 })
 ```
 
-### 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.
 
@@ -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.
 

@@ -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()`
 

@@ -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.
 

@@ -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.

@@ -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.