@intlayer/docs 9.4.4 → 9.5.1

package/blog/en/transform_existing_vite_react_app_using_compiler.md

@@ -0,0 +1,351 @@
+---
+createdAt: 2024-03-07
+updatedAt: 2026-09-06
+title: How to Make Multilingual (i18n) an Existing Vite and React Application Afterward (i18n Guide 2026)
+description: The 2026 guide to making an existing Vite and React app multilingual (i18n) without tedious refactoring. Discover zero-effort content extraction, AI translation, and high-performance bundling with Intlayer.
+keywords:
+  - Vite i18n
+  - React i18n
+  - Internationalization
+  - Translate existing Vite app
+  - Translate existing React app
+  - Intlayer
+  - Multilingual
+  - Compiler
+  - AI translation
+  - SEO
+slugs:
+  - blog
+  - transform-existing-react-app-into-multilingual-app
+applicationTemplate: https://github.com/aymericzip/intlayer-vite-react-template
+applicationShowcase: https://intlayer-vite-react-template.vercel.app
+youtubeVideo: https://www.youtube.com/watch?v=dS9L7uJeak4
+history:
+  - version: 8.9.0
+    date: 2026-05-04
+    changes: "Update Solid useIntlayer API usage to direct property access"
+  - version: 8.2.0
+    date: 2026-03-09
+    changes: "Update compiler options, add FilePathPattern support"
+  - version: 8.1.6
+    date: 2026-02-23
+    changes: "Initial release"
+author: aymericzip
+---
+
+# How to make multilingual (i18n) an existing Vite and React application afterward (i18n guide 2026)
+
+Adding internationalization (i18n) to a Vite and React project from day one is relatively straightforward. But what happens when you already have a mature, production-ready single-language application and need to make it multilingual **afterward**?
+
+If you have ever attempted this with traditional libraries like `react-i18next` or `react-intl`, you know the friction:
+
+- Hunting down hardcoded strings across hundreds of JSX and TSX files.
+- Manually creating nested JSON files and inventing arbitrarily named translation keys (`components.header.title`, etc.).
+- Replacing JSX text with cumbersome translation hook calls (`t('...')`).
+- Re-architecting client-side routing, state management, and locale switching logic.
+
+In 2026, you do not have to rewrite your codebase to make your Vite and React application multilingual. With **Intlayer**, you can retrofit internationalization onto an existing app in minutes, using automated extraction, AI-powered translation, and non-invasive routing.
+
+> Looking for the complete, step-by-step technical guide for Vite and React? Check out our dedicated documentation: [Translate Vite and React with Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/intlayer_with_vite+react.md).
+
+## Table of Contents
+
+<TOC/>
+
+## The Retrofit Dilemma: Why Making an Existing Vite and React App Multilingual Is Hard
+
+When internationalizing an existing Vite and React application, developers face three major obstacles:
+
+1. **Codebase Disruption**: Manually extracting strings into JSON dictionaries requires modifying almost every component file. This produces huge git diffs, creates merge conflict risks, and introduces potential layout regressions.
+2. **Key Maintenance Overhead**: Inventing keys like `dashboard.hero.ctaButton` for every text snippet slows development down and introduces cognitive load every time UI copy changes.
+3. **Translation Grunt Work**: Once strings are extracted, populating dictionaries in 5, 10, or 20 languages involves endless copy-pasting or expensive external translation services.
+
+Intlayer solves these challenges at the architectural level with **compiler-assisted extraction**, **declarative component-level dictionaries**, and **seamless Vite integration**.
+
+## Automated Content Extraction (No Manual String Hunting)
+
+Instead of manually extracting every hardcoded string from your JSX, Intlayer provides two zero-friction paths:
+
+### Option A: The CLI Extractor (`npx intlayer extract`)
+
+You can run Intlayer's extraction tool directly on your codebase:
+
+```bash packageManager="npm"
+npx intlayer extract
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer extract
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer extract
+```
+
+```bash packageManager="bun"
+bunx intlayer extract
+```
+
+This command parses your React components, extracts user-facing strings, and automatically creates per-component content declaration files (`.content.ts`) right alongside your components. Your component logic remains declarative, clear, and fully type-safe without having to write a single translation key by hand.
+
+### Option B: The Intlayer Compiler (Build-Time Extraction)
+
+With the Intlayer Compiler enabled in your configuration, you can continue writing your components with plain, hardcoded text in your default language. At build time, the compiler extracts the text and injects the localized content automatically:
+
+```tsx fileName="src/App.tsx"
+// Write normal React code. The compiler extracts the text automatically
+export default function App() {
+  return (
+    <section>
+      <h1>Welcome to our platform</h1>
+      <p>Start exploring our modern features today.</p>
+    </section>
+  );
+}
+```
+
+Behind the scenes, Intlayer builds the dictionary and links the component to its localized content, completely eliminating manual refactoring.
+
+In this case, it generates a `src/App.content.ts` declaration file with the following structure:
+
+```typescript fileName="src/App.content.ts"
+import { Dictionary } from "intlayer";
+
+const content = {
+  key: "app",
+  content: {
+    welcomeToOurPlatform: t({ en: "Welcome to our platform" }),
+    startExploringOurModernFeaturesToday: t({
+      en: "Start exploring our modern features today.",
+    }),
+  },
+};
+
+export default content;
+```
+
+## AI-Powered Translation with Your Favorite LLM
+
+Once your content is extracted, translating it into dozens of languages should not take days. Intlayer includes a built-in AI translation CLI that integrates directly with OpenAI, Anthropic, DeepSeek, or Mistral using your own API keys:
+
+```bash packageManager="npm"
+npx intlayer fill
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer fill
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer fill
+```
+
+```bash packageManager="bun"
+bunx intlayer fill
+```
+
+Configure your locales and AI provider in `intlayer.config.ts`:
+
+```typescript fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH, Locales.GERMAN],
+    defaultLocale: Locales.ENGLISH,
+  },
+  ai: {
+    provider: "openai",
+    model: "gpt-4o-mini",
+    apiKey: process.env.OPENAI_API_KEY,
+    applicationContext:
+      "Modern SaaS application and dashboard built with Vite and React",
+  },
+};
+
+export default config;
+```
+
+Running `npx intlayer fill` populates your content declarations with high-quality translations for your configured locales:
+
+```typescript fileName="src/App.content.ts"
+import { Dictionary } from "intlayer";
+
+const content = {
+  key: "app",
+  content: {
+    welcomeToOurPlatform: t({
+      en: "Welcome to our platform",
+      fr: "Bienvenue sur notre plateforme",
+      es: "Bienvenido a nuestra plataforma",
+      de: "Willkommen auf unserer Plattform",
+    }),
+    startExploringOurModernFeaturesToday: t({
+      en: "Start exploring our modern features today.",
+      fr: "Découvrez nos fonctionnalités modernes dès aujourd'hui.",
+      es: "Comience a explorar nuestras funciones modernas hoy.",
+      de: "Entdecken Sie noch heute unsere modernen Funktionen.",
+    }),
+  },
+};
+
+export default content;
+```
+
+Because Intlayer provides high-level `applicationContext` to the LLM, generated translations preserve technical nuance, brand tone, and grammatical context far better than traditional generic translation tools.
+
+To verify that no strings were missed before deploying to production:
+
+```bash
+npx intlayer test
+```
+
+## Vite Integration and Provider Setup
+
+Integrating Intlayer into Vite requires adding the plugin to `vite.config.ts` and wrapping your root component with `IntlayerProvider`:
+
+```typescript fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import react from "@vitejs/plugin-react-swc";
+import { intlayer } from "vite-intlayer";
+
+export default defineConfig({
+  plugins: [react(), intlayer()],
+});
+```
+
+> Since Intlayer v9, the compiler is bundled directly into the `intlayer()` plugin and activates automatically once `compiler.enabled` is configured in `intlayer.config.ts`.
+
+Wrap your application with `IntlayerProvider` in your root component:
+
+```tsx fileName="src/App.tsx"
+import { FC } from "react";
+import { IntlayerProvider } from "react-intlayer";
+import { MainContent } from "./MainContent";
+
+const App: FC = () => {
+  return (
+    <IntlayerProvider>
+      <MainContent />
+    </IntlayerProvider>
+  );
+};
+
+export default App;
+```
+
+### Changing Locales Dynamically
+
+Switch languages easily anywhere in your application using the `useLocale` hook:
+
+```tsx fileName="src/components/LocaleSwitcher.tsx"
+import { FC } from "react";
+import { Locales } from "intlayer";
+import { useLocale } from "react-intlayer";
+
+export const LocaleSwitcher: FC = () => {
+  const { locale, setLocale, availableLocales } = useLocale();
+
+  return (
+    <select
+      value={locale}
+      onChange={(e) => setLocale(e.target.value as Locales)}
+    >
+      {availableLocales.map((loc) => (
+        <option key={loc} value={loc}>
+          {loc}
+        </option>
+      ))}
+    </select>
+  );
+};
+```
+
+## Multilingual SEO (Sitemap and Robots.txt)
+
+Intlayer includes formatters such as `generateSitemap` and `getMultilingualUrls` that produce crawler-ready multilingual `sitemap.xml` and `robots.txt` output for static Vite deployments:
+
+```javascript fileName="generate-seo.mjs"
+import fs from "fs";
+import path from "path";
+import { fileURLToPath } from "url";
+import { generateSitemap, getMultilingualUrls } from "intlayer";
+
+const __dirname = path.dirname(fileURLToPath(import.meta.url));
+const SITE_URL = (process.env.SITE_URL || "https://example.com").replace(
+  /\/$/,
+  ""
+);
+
+const pathList = [
+  { path: "/", changefreq: "daily", priority: 1.0 },
+  { path: "/about", changefreq: "monthly", priority: 0.7 },
+];
+
+const sitemapXml = generateSitemap(pathList, { siteUrl: SITE_URL });
+fs.writeFileSync(path.join(__dirname, "public", "sitemap.xml"), sitemapXml);
+
+const getAllMultilingualUrls = (urls) =>
+  urls.flatMap((url) => Object.values(getMultilingualUrls(url)));
+
+const disallowedPaths = getAllMultilingualUrls(["/admin", "/private"]);
+
+const robotsTxt = [
+  "User-agent: *",
+  "Allow: /",
+  ...disallowedPaths.map((path) => `Disallow: ${path}`),
+  "",
+  `Sitemap: ${SITE_URL}/sitemap.xml`,
+].join("\n");
+
+fs.writeFileSync(path.join(__dirname, "public", "robots.txt"), robotsTxt);
+console.log("SEO files generated successfully.");
+```
+
+Add a `prebuild` hook to your `package.json` to run this script before `vite build`:
+
+```json fileName="package.json"
+{
+  "scripts": {
+    "dev": "vite",
+    "prebuild": "node generate-seo.mjs",
+    "build": "vite build",
+    "preview": "vite preview"
+  }
+}
+```
+
+## Deep-Dive: Ready for the Step-by-Step Implementation?
+
+This guide provided a high-level overview of how to retrofit internationalization into an existing Vite and React app in 2026 without architectural headaches.
+
+If you are ready to configure every part of your Vite and React application step-by-step, including detailed configuration options, TypeScript type safety, dynamic dictionaries, and visual editing, head over to our comprehensive documentation guide:
+
+👉 **[Complete Guide to Translating Vite and React with Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/intlayer_with_vite+react.md)**
+
+## Frequently Asked Questions (FAQ)
+
+<FAQ>
+
+<Question title="Can I make my Vite and React app multilingual without manually refactoring all strings?">
+
+Yes. You can use `npx intlayer extract` to automatically detect and extract hardcoded strings into localized content declarations, or use the Intlayer Compiler to transform components at build time so you can keep writing standard JSX.
+
+</Question>
+<Question title="How does Intlayer reduce Vite bundle size compared to react-i18next or react-intl?">
+
+Intlayer uses per-component dictionary definitions and build-time macro optimization. Bundles only receive the exact fields needed by the components rendered on the page, rather than importing entire namespace JSON files. Dynamic dictionaries can also lazy-load languages on demand.
+
+</Question>
+<Question title="Can I use AI to translate my existing components into multiple languages?">
+
+Yes. Intlayer's CLI includes the `npx intlayer fill` command, which connects to your preferred AI provider (OpenAI, Anthropic, Mistral, DeepSeek) to generate contextual translations for missing locales across your entire project.
+
+</Question>
+<Question title="Can I migrate from react-i18next or react-intl without rewriting my components?">
+
+Yes. Intlayer provides compatibility adapters for `react-i18next` and `react-intl`, as well as plugins to synchronize existing JSON translation files (`sync-json`).
+
+</Question>
+
+</FAQ>

package/blog/en/vue-i18n_vs_intlayer.md

@@ -35,15 +35,11 @@ We focus on modern Vue tooling (Vite, Composition API) and evaluate:
 
 > **tl;dr**: Both can localize Vue apps. If you want **component-scoped content**, **strict TypeScript types**, **build-time missing-key checks**, **tree-shaken dictionaries**, and **batteries-included router/SEO helpers** plus **Visual Editor & AI translations**, **Intlayer** is the more complete, modern choice.
 
----
-
 ## High-level positioning
 
 - **vue-i18n** - The de-facto i18n library for Vue. Flexible message formatting (ICU-style), SFC `<i18n>` blocks for local messages, and a big ecosystem. Safety and large-scale maintenance are mostly on you.
 - **Intlayer** - Component-centric content model for Vue/Vite/Nuxt with **strict TS typing**, **build-time checks**, **tree-shaking**, **router & SEO helpers**, optional **Visual Editor/CMS**, and **AI-assisted translations**.
 
----
-
 ## Side-by-Side Feature Comparison (Vue-focused)
 
 | Feature                                     | **Intlayer**                                                                     | **vue-i18n**                                                                 |
@@ -67,8 +63,6 @@ We focus on modern Vue tooling (Vite, Composition API) and evaluate:
 | **Large-project maintainability**           | ✅ Encourages modular, design-system-friendly structure                          | ✅ Possible, but needs strong file/namespace discipline                      |
 | **Ecosystem / community**                   | ⚠️ Smaller but growing fast                                                      | ✅ Large and mature in the Vue ecosystem                                     |
 
----
-
 ## Deep-dive comparison
 
 ### 1) Architecture & scalability
@@ -78,8 +72,6 @@ We focus on modern Vue tooling (Vite, Composition API) and evaluate:
 
 **Why it matters:** In large Vue apps or design systems, **modular content** scales better than monolithic catalogs.
 
----
-
 ### 2) TypeScript & safety
 
 - **vue-i18n**: Good TS support; **strict key typing** typically needs custom schemas/generics and careful conventions.
@@ -87,8 +79,6 @@ We focus on modern Vue tooling (Vite, Composition API) and evaluate:
 
 **Why it matters:** Strong typing catches issues **before** runtime.
 
----
-
 ### 3) Missing translation handling
 
 - **vue-i18n**: **Runtime** warnings/fallbacks (e.g., fall back locale or key).
@@ -96,8 +86,6 @@ We focus on modern Vue tooling (Vite, Composition API) and evaluate:
 
 **Why it matters:** Build-time enforcement keeps production UI clean and consistent.
 
----
-
 ### 4) Routing & URL strategy (Vue Router/Nuxt)
 
 - **Both** can work with localized routes.
@@ -105,8 +93,6 @@ We focus on modern Vue tooling (Vite, Composition API) and evaluate:
 
 **Why it matters:** Fewer custom glue layers and **cleaner SEO** across locales.
 
----
-
 ### 5) Performance & loading behavior
 
 - **vue-i18n**: Supports async locale messages; avoiding over-bundling is on you (split catalogs carefully).
@@ -114,8 +100,6 @@ We focus on modern Vue tooling (Vite, Composition API) and evaluate:
 
 **Why it matters:** Smaller bundles and faster startup for multi-locale Vue apps.
 
----
-
 ### 6) Developer experience & tooling
 
 - **vue-i18n**: Mature docs and community; you’ll typically rely on **external localization platforms** for editorial workflows.
@@ -123,8 +107,6 @@ We focus on modern Vue tooling (Vite, Composition API) and evaluate:
 
 **Why it matters:** Lower ops cost and a shorter dev–content loop.
 
----
-
 ### 7) SEO, SSR & SSG
 
 - **Both** work with Vue SSR and Nuxt.
@@ -132,8 +114,6 @@ We focus on modern Vue tooling (Vite, Composition API) and evaluate:
 
 **Why it matters:** International SEO without bespoke wiring.
 
----
-
 ## Why Intlayer? (Problem & approach)
 
 Most i18n stacks (including **vue-i18n**) start from **centralized catalogs**:
@@ -223,8 +203,6 @@ This approach:
 - **Avoids dead keys** (unused components don’t import content).
 - **Optimizes loading** (lazy-loaded components bring their content with them).
 
----
-
 ## Additional features of Intlayer (Vue-relevant)
 
 - **Cross-framework support**: Works with Vue, Nuxt, Vite, React, Express, and more.
@@ -242,31 +220,23 @@ This approach:
 - **MCP server & VSCode extension**: Automate i18n workflows and authoring inside your IDE.
 - **Interoperability**: Bridges with **vue-i18n**, **react-i18next**, and **react-intl** when needed.
 
----
-
 ## When to choose which?
 
 - **Choose vue-i18n** if you want the **standard Vue approach**, you’re comfortable managing catalogs/namespaces yourself, and your app is **small to mid-size** (or you already rely on Nuxt i18n).
 - **Choose Intlayer** if you value **component-scoped content**, **strict TypeScript**, **build-time guarantees**, **tree-shaking**, and **batteries-included** routing/SEO/editor tooling-especially for **large, modular Vue/Nuxt codebases**, design-systems, etc.
 
----
-
 ## Interoperability with vue-i18n
 
 `intlayer` can also help to manage your `vue-i18n` namespaces.
 
 Using `intlayer`, you can declare your content in the format of your favorite i18n library, and intlayer will generate your namespaces in the location of your choice (example: `/messages/{{locale}}/{{namespace}}.json`).
 
----
-
 ## GitHub STARs
 
 GitHub stars are a strong indicator of a project's popularity, community trust, and long-term relevance. While not a direct measure of technical quality, they reflect how many developers find the project useful, follow its progress, and are likely to adopt it. For estimating the value of a project, stars help compare traction across alternatives and provide insights into ecosystem growth.
 
 [![Star History Chart](https://api.star-history.com/svg?repos=intlify/vue-i18n&repos=aymericzip/intlayer&type=Date)](https://www.star-history.com/#intlify/vue-i18n&aymericzip/intlayer)
 
----
-
 ## Conclusion
 
 Both **vue-i18n** and **Intlayer** localize Vue apps well. The difference is **how much you must build yourself** to achieve a robust, scalable setup:

package/blog/en/what_is_internationalization.md

@@ -101,8 +101,6 @@ This concise overview covers the main elements that should be internationalized,
 - **Cultural Sensitivities**  
   Icons, colors, and symbols might carry different meanings across cultures. It’s important to adapt visual and textual content to respect local cultural nuances.
 
----
-
 ## Best Practices for Implementing i18n
 
 - **Plan Early**  
@@ -117,8 +115,6 @@ This concise overview covers the main elements that should be internationalized,
 - **Translations Reusability**  
   Organize your translation files to be reusable across multiple websites or applications. For instance, if you have a multilingual footer or header, set up dedicated translation files so that common elements can be easily applied to all projects.
 
----
-
 ## Locale Dictionary vs. CMS Content Externalization
 
 When creating a website, a **Content Management System (CMS) like WordPress, Wix, or Drupal generally offer improved maintainability**. Especially for blogs or landing pages, because of their integrated i18n features.
@@ -136,8 +132,6 @@ Given these challenges, it's common to opt for a headless CMS to externalize con
 
 It is important to choose the right tool for your needs and plan your internationalization strategy from the beginning. **Intlayer offers a compelling solution by combining locale content declaration with a headless CMS that is tightly integrated, providing the best of both worlds.**
 
----
-
 ### See list of i18n Libraries and tool per technology
 
 If you’re looking for a list of i18n libraries and tools per technology, check out the following resources:
@@ -156,8 +150,6 @@ If you’re looking for a list of i18n libraries and tools per technology, check
 - Svelte: [See list of i18n Libraries and tool](https://github.com/aymericzip/intlayer/blob/main/docs/blog/en/list_i18n_technologies/frameworks/svelte.md)
 - React Native : [See list of i18n Libraries and tool](https://github.com/aymericzip/intlayer/blob/main/docs/blog/en/list_i18n_technologies/frameworks/react-native.md)
 
----
-
 ## Conclusion
 
 Internationalization (i18n) is more than just a technical chore; it’s a **strategic investment** that enables your software to speak the language of your users literally. By abstracting away locale-specific elements, accommodating linguistic and cultural variations, and planning for future expansion, you empower your product to thrive in a global marketplace.

package/blog/en-GB/hreflang_guide_multilingual_seo.md

@@ -25,8 +25,6 @@ You translated your app. You shipped `/en`, `/fr`, `/es`. And French users still
 
 Translating is the easy half. The hard half is telling search engines that these pages are the **same page in another language**, not three documents competing with each other. That is what `hreflang` does, and it is where most multilingual sites quietly lose their traffic.
 
----
-
 ## What hreflang actually is
 
 An annotation on a page saying: _this URL has equivalent versions over there, for those languages._
@@ -42,8 +40,6 @@ It gives you two things: the correct version shown to the correct user, and your
 
 It is worth being clear about what it is not. It is **not a redirect** — it is a hint, and Google may override it. It is **not a ranking boost** — it changes _which_ version ranks, not _whether_ you rank. And Bing ignores it entirely, relying on `content-language` and geo-targeting instead.
 
----
-
 ## Where to declare it
 
 Three placements, all valid. Pick one and stay there — the same cluster declared in two places is how sets drift apart.
@@ -54,8 +50,6 @@ Three placements, all valid. Pick one and stay there — the same cluster declar
 
 **HTTP `Link` header** is the only option for non-HTML files like PDFs.
 
----
-
 ## The rules
 
 ### Self-reference and reciprocity
@@ -107,8 +101,6 @@ What people get wrong is what it means. `x-default` is **not "the English versio
 
 Two things to keep straight: `x-default` is one extra entry in the set, not a replacement for the self-referencing one, and like every other entry it must appear identically on every page in the cluster.
 
----
-
 ## The canonical trap
 
 Each localised page must be **its own canonical**:
@@ -131,8 +123,6 @@ states that the French page is a duplicate that should not be indexed, whilst `h
 
 **Canonical is self-referential per locale. `hreflang` describes the cluster.**
 
----
-
 ## Choosing a URL structure
 
 `hreflang` annotates URLs, so the structure comes first.
@@ -149,14 +139,11 @@ The one structure to avoid: serving different languages at the **same URL** base
 
 > Intlayer covers all three through `routing.mode` and `routing.domains`. See [custom domains](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en-GB/custom_domains.md) and the [configuration reference](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en-GB/configuration.md).
 
----
-
 ## Implementation
 
 Writing these tags by hand does not survive contact with a second locale. Derive them from your locale list instead.
 
 <Steps>
-
 <Step number={1} title="Emit the cluster on every page">
 
 Same set everywhere, canonical per locale, absolute URLs, `x-default` included.
@@ -245,7 +232,6 @@ export const Route = createFileRoute("/{-$locale}/about")({
 </Tabs>
 
 </Step>
-
 <Step number={2} title="Or move it all to the sitemap">
 
 At scale, keep the annotations out of your pages entirely. `generateSitemap` emits `xhtml:link` alternates per entry, reading locales and routing mode from your config:
@@ -268,7 +254,6 @@ Two options worth knowing:
 - `entryPerLocale` (default `false`) — by default one `<url>` entry carries all the alternates. Both forms are valid, but only a URL listed as a `<loc>` counts as _submitted_ in Search Console; alternate-only locales stay discoverable yet attributed to no sitemap. Turning this on gives every localised URL its own entry with the full alternate set repeated. It multiplies entries by locale count, so watch the 50 000 URL / 50 MB limit and split into a sitemap index past it.
 
 </Step>
-
 <Step number={3} title="Verify what the crawler receives">
 
 `hreflang` fails silently, so check it rather than assume it.
@@ -281,8 +266,6 @@ For a multilingual-specific crawl, the [Intlayer SEO Scanner](https://intlayer.o
 
 </Steps>
 
----
-
 ## Checklist
 
 - [ ] Each locale has a distinct, crawlable URL
@@ -296,8 +279,6 @@ For a multilingual-specific crawl, the [Intlayer SEO Scanner](https://intlayer.o
 - [ ] Declared in exactly one place
 - [ ] No alternate redirects
 
----
-
 ## Wrapping up
 
 `hreflang` is simple and unforgiving. One missing return tag, one relative URL, one cross-locale canonical, and the cluster is discarded with no error anywhere. Every one of those comes from writing the tags by hand.

package/blog/en-GB/i18n_meaning.md

@@ -92,8 +92,6 @@ Now that we have established the true **i18n meaning**, how do you apply it?
 - **Abstract all user-facing text:** Ensure that zero hardcoded text exists in your UI components.
 - **Employ a robust translation management system:** Tools like **Intlayer** bridge the gap between developers and translators. Intlayer acts as a headless CMS that is tightly integrated with your codebase, allowing content managers to update translations visually without requiring a developer to trigger a new build.
 
----
-
 ### View List of i18n Libraries and Tools per Technology
 
 If you are looking for a list of i18n libraries and tools per technology, check the following resources:
@@ -112,8 +110,6 @@ If you are looking for a list of i18n libraries and tools per technology, check
 - Svelte: [View list of i18n libraries and tools](https://github.com/aymericzip/intlayer/blob/main/docs/blog/en-GB/list_i18n_technologies/frameworks/svelte.md)
 - React Native: [View list of i18n libraries and tools](https://github.com/aymericzip/intlayer/blob/main/docs/blog/en-GB/list_i18n_technologies/frameworks/react-native.md)
 
----
-
 ## Conclusion
 
 The **i18n meaning** is a fundamental concept for any modern digital business aiming for global impact. Far from just being a quirky technical shorthand for "internationalisation", i18n represents the technical architecture required to seamlessly adapt your software for various languages, cultures, and regional standards.