@intlayer/docs 9.4.3 → 9.5.0

package/blog/en-GB/list_i18n_technologies/frameworks/react.md

@@ -23,16 +23,12 @@ author: aymericzip
 
 In today's digital landscape, expanding your website’s reach to cater to a global audience is essential. For developers building with React, implementing internationalization (i18n) is key to managing translations efficiently while preserving application structure, SEO value, and user experience. In this article, we explore various i18n approaches, from dedicated libraries to custom-coded solutions, helping you decide which one best suits your project needs.
 
----
-
 ## What is Internationalization (i18n)?
 
 Internationalization, abbreviated as i18n, is the process of designing and preparing your website to support multiple languages and cultural contexts. In React, this means setting up your app so that strings, date formats, number formats, and even the layout can be adapted easily for users from different regions. Preparing your React app for i18n lays the groundwork for cleanly integrating translations and other localization features.
 
 Learn more about i18n by reading our article: [What is Internationalization (i18n)? Definition and Challenges](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en-GB/what_is_internationalization.md).
 
----
-
 ## The Translation Challenge for React Applications
 
 Translating a React website presents several challenges:
@@ -43,8 +39,6 @@ Translating a React website presents several challenges:
 - **State and Context Management:** Ensuring that the correct language is maintained across routes and components requires thoughtful state management.
 - **Development Overhead:** Maintaining translation files, ensuring context accuracy, and keeping your application scalable are ongoing considerations.
 
----
-
 ## Leading i18n Solutions for React
 
 Below are several popular approaches to managing multilingual content in React applications, each designed to streamline the translation process in different ways.
@@ -69,8 +63,6 @@ Below are several popular approaches to managing multilingual content in React a
 
 - **Community & Ecosystem**: Though growing, the ecosystem is newer, so community-driven plugins and tooling may be more limited compared to more established solutions.
 
----
-
 ### 2. React-i18next
 
 Website: [https://react.i18next.com/](https://react.i18next.com/)
@@ -93,8 +85,6 @@ Website: [https://react.i18next.com/](https://react.i18next.com/)
 - **Plugin Ecosystem**: A broad ecosystem of plugins and middlewares is available, which also means you’ll need to sift through various packages to find the right tools.
 - **Server Components**: Requires additional setup to ensure server components pick up the correct locales, especially if using frameworks other than Next.js.
 
----
-
 ### 3. React Intl (from FormatJS)
 
 Website: [https://formatjs.io/docs/react-intl/](https://formatjs.io/docs/react-intl/)
@@ -137,8 +127,6 @@ Website: [https://lingui.js.org/](https://lingui.js.org/)
 - **Community & Plugins**: The ecosystem is growing but still smaller compared to i18next or FormatJS.
 - **Server Components**: May need more explicit configuration to ensure that server components receive the correct locale data.
 
----
-
 ### Final Thoughts
 
 When choosing an i18n library for React:

package/blog/en-GB/list_i18n_technologies/frameworks/svelte.md

@@ -23,16 +23,12 @@ author: aymericzip
 
 As the web continues to connect people across the globe, providing content in multiple languages is increasingly important. For developers working with **Svelte**, implementing i18n is essential to efficiently manage translations, maintain clean code, and uphold good SEO practices. In this article, we dive into various i18n solutions and workflows for Svelte, helping you choose the one that best suits your project’s needs.
 
----
-
 ## What is Internationalization (i18n)?
 
 Internationalization, commonly abbreviated as i18n, is the process of designing and building your application so it can easily adapt to various languages, regions, and cultural conventions. In Svelte, this typically means setting up translation strings, localizing dates, times, and numbers, and ensuring the user interface can dynamically switch among different locales without major code rewrites.
 
 To learn more about i18n fundamentals, read our article: [What is Internationalization (i18n)? Definition and Challenges](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en-GB/what_is_internationalization.md).
 
----
-
 ## The Translation Challenge for Svelte Applications
 
 Translating a Svelte application can present several hurdles:
@@ -43,8 +39,6 @@ Translating a Svelte application can present several hurdles:
 - **State & Routing**: Retaining the correct language across multiple routes and dynamic pages often involves orchestrating global state, route guards, or custom hooks in SvelteKit.
 - **Maintainability**: As your codebase and translation files grow, keeping everything well-organised and synchronised becomes a continuous effort.
 
----
-
 ## Leading i18n Solutions for Svelte
 
 Svelte doesn’t provide a native, built-in i18n solution (as Angular does), but the community has created a variety of robust libraries and patterns. Below are several popular approaches.
@@ -69,8 +63,6 @@ Svelte doesn’t provide a native, built-in i18n solution (as Angular does), but
 
 - **Community & Ecosystem**: Though growing, the ecosystem is newer, so community-driven plugins and tooling may be more limited compared to more established solutions.
 
----
-
 ### 2. svelte-i18n
 
 Repository: [https://github.com/kaisermann/svelte-i18n](https://github.com/kaisermann/svelte-i18n)
@@ -91,8 +83,6 @@ Repository: [https://github.com/kaisermann/svelte-i18n](https://github.com/kaise
 - **SSR Setup**: Configuring SSR for SEO might require additional steps to ensure correct locale detection on the server side.
 - **Performance**: While flexible at runtime, a large number of translations loaded at once can impact initial load times, consider lazy loading or caching strategies.
 
----
-
 ### 3. svelte-intl-precompile
 
 Repository: [https://github.com/cibernox/svelte-intl-precompile](https://github.com/cibernox/svelte-intl-precompile)
@@ -113,8 +103,6 @@ Repository: [https://github.com/cibernox/svelte-intl-precompile](https://github.
 - **Dynamic Content**: If you need on-the-fly translations for user-generated content, this approach may require extra steps for updates at runtime.
 - **Learning Curve**: The combination of message extraction and precompilation can be slightly more complex for newcomers.
 
----
-
 ### 4. i18next with Svelte / SvelteKit
 
 Website: [https://www.i18next.com/](https://www.i18next.com/)
@@ -135,8 +123,6 @@ Although **i18next** is more commonly associated with React or Vue, it’s also
 - **Overhead**: i18next is robust, but for smaller Svelte projects, some of its features might be overkill.
 - **Routing & State**: Handling language routing will likely involve custom SvelteKit hooks or middlewares.
 
----
-
 ### Final Thoughts
 
 When selecting an i18n strategy for your Svelte app:

package/blog/en-GB/list_i18n_technologies/frameworks/vue.md

@@ -23,16 +23,12 @@ author: aymericzip
 
 In an increasingly globalized digital landscape, extending your Vue.js website’s reach to users in multiple languages is no longer a “nice-to-have”, it’s a competitive necessity. Internationalization (i18n) enables developers to manage translations and adapt their applications for various locales while preserving SEO value, user experience, and maintainable code structures. In this article, we’ll explore different approaches, ranging from dedicated libraries to custom-coded solutions, that help you integrate i18n into your Vue.js project smoothly.
 
----
-
 ## What is Internationalization (i18n)?
 
 Internationalization (i18n) is the practice of preparing a software application (or website) for multiple languages and cultural conventions. Within the Vue.js ecosystem, this includes establishing how text, dates, numbers, currency, and other localizable elements can be adapted to various locales. By setting up i18n from the start, you ensure an organized, scalable structure for adding new languages and handling future localization needs.
 
 To learn more about i18n basics, check out our reference: [What is Internationalization (i18n)? Definition and Challenges](https://github.com/aymericzip/intlayer/blob/main/docs/blog/en-GB/what_is_internationalization.md).
 
----
-
 ## The Translation Challenge for Vue Applications
 
 Translating a Vue.js application brings its own set of challenges:
@@ -43,14 +39,10 @@ Translating a Vue.js application brings its own set of challenges:
 - **State and Reactive Context:** Ensuring that the current locale is maintained across routes and components, reactively updating texts and formats, requires a thoughtful approach, especially when dealing with Vuex or Pinia for state management.
 - **Development Overhead:** Keeping translation files organized, consistent, and up to date can quickly become a major task if not managed carefully.
 
----
-
 ## Leading i18n Solutions for Vue.js
 
 Below are several popular libraries and approaches you can use to incorporate internationalization into your Vue applications. Each aims to streamline translation, SEO, and performance considerations in different ways.
 
----
-
 ### 1. Intlayer
 
 > Website: [https://intlayer.org/](https://intlayer.org/)
@@ -94,8 +86,6 @@ Below are several popular libraries and approaches you can use to incorporate in
 - **Plugin Ecosystem**  
   While robust, you may need to carefully select from multiple plugins or modules (Nuxt I18n, Vue I18n, etc.) to build a perfect setup.
 
----
-
 ### 3. LinguiJS (Vue Integration)
 
 > Website: [https://lingui.js.org/](https://lingui.js.org/)
@@ -123,8 +113,6 @@ Originally known for its React integration, **LinguiJS** also offers a Vue plugi
 - **Smaller Community**  
   Compared to Vue I18n, there’s a relatively smaller ecosystem. Officially maintained plugins and third-party add-ons can be more limited.
 
----
-
 ## Final Thoughts
 
 When deciding on an i18n solution for your Vue.js application:

package/blog/en-GB/next-i18next_vs_next-intl_vs_intlayer.md

@@ -42,16 +42,12 @@ We focus on **Next.js 13+ App Router** (with **React Server Components**) and ev
 
 > One confusion often made by developers is to think that `next-intl` is the Next.js version of `react-intl`. It's not, `next-intl` is maintained by [Amann](https://github.com/amannn), while `react-intl` is maintained by [FormatJS](https://github.com/formatjs/formatjs).
 
----
-
 ## In short
 
 - **next-intl** - Lightweight, straightforward message formatting with solid Next.js support. Centralised catalogues are common; DX is simple, but safety and large-scale maintenance remain mostly your responsibility.
 - **next-i18next** - i18next in Next.js clothing. Mature ecosystem and features via plugins (e.g., ICU), but configuration can be verbose and catalogues tend to centralise as projects grow.
 - **Intlayer** - Component-centric content model for Next.js, **strict TS typing**, **build-time checks**, **tree-shaking**, **built-in middleware & SEO helpers**, optional **Visual Editor/CMS**, and **AI-assisted translations**.
 
----
-
 | Library                | GitHub Stars                                                                                                                                                                     | Total Commits                                                                                                                                                                        | Last Commit                                                                                                                                           | First Version | NPM Version                                                                                                         | NPM Downloads                                                                                                                  |
 | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
 | `aymericzip/intlayer`  | [![GitHub Repo stars](https://img.shields.io/github/stars/aymericzip/intlayer?style=for-the-badge&label=%E2%AD%90%20stars)](https://github.com/aymericzip/intlayer/stargazers)   | [![GitHub commit activity](https://img.shields.io/github/commit-activity/t/aymericzip/intlayer?style=for-the-badge&label=commits)](https://github.com/aymericzip/intlayer/commits)   | [![Last Commit](https://img.shields.io/github/last-commit/aymericzip/intlayer?style=for-the-badge)](https://github.com/aymericzip/intlayer/commits)   | April 2024    | [![npm](https://img.shields.io/npm/v/intlayer?style=for-the-badge)](https://www.npmjs.com/package/intlayer)         | [![npm downloads](https://img.shields.io/npm/dm/intlayer?style=for-the-badge)](https://www.npmjs.com/package/intlayer)         |
@@ -61,8 +57,6 @@ We focus on **Next.js 13+ App Router** (with **React Server Components**) and ev
 
 > Badges update automatically. Snapshots will vary over time.
 
----
-
 ## Side-by-Side Feature Comparison (Next.js focused)
 
 | Feature                                       | `next-intlayer` (Intlayer)                                                                                                          | `next-intl`                                                                                              | `next-i18next`                                                                                           |
@@ -88,16 +82,12 @@ We focus on **Next.js 13+ App Router** (with **React Server Components**) and ev
 | **Management of Large Projects**              | ✅ Encourages modular, suited for design system                                                                                     | ✅ Modular with setup                                                                                    | ✅ Modular with setup                                                                                    |
 | **Testing Missing Translations (CLI/CI)**     | ✅ CLI: `npx intlayer content test` (CI-friendly audit)                                                                             | ⚠️ Not built-in; docs suggest `npx @lingual/i18n-check`                                                  | ⚠️ Not built-in; rely on i18next tools / runtime `saveMissing`                                           |
 
----
-
 ## Introduction
 
 Next.js provides built-in support for internationalised routing (e.g. locale segments). However, that feature does not perform translations on its own. You still need a library to render localised content to your users.
 
 Many i18n libraries exist, but in the Next.js ecosystem today, three are gaining traction: next-i18next, next-intl, and Intlayer.
 
----
-
 ## Architecture & scalability
 
 - **next-intl / next-i18next**: Default to **centralised catalogues** per locale (plus **namespaces** in i18next). Works fine early on, but often becomes a large shared surface area with increasing coupling and key churn.
@@ -105,8 +95,6 @@ Many i18n libraries exist, but in the Next.js ecosystem today, three are gaining
 
 **Why it matters:** In large codebases or design-system setups, **modular content** scales better than monolithic catalogues.
 
----
-
 ## Bundle sizes & dependencies
 
 After building the application, the bundle is the JavaScript that the browser will load to render the page. Bundle size is therefore important for application performance.
@@ -172,8 +160,6 @@ Here is an example of the impact of bundle size optimisation using `intlayer` in
 | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
 | ![optimised bundle](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle.png?raw=true) | ![no optimised bundle](https://github.com/aymericzip/intlayer/blob/main/docs/assets/bundle_no_optimization.png?raw=true) |
 
----
-
 ## TypeScript & safety
 
 <Columns>
@@ -198,12 +184,11 @@ Here is an example of the impact of bundle size optimisation using `intlayer` in
 - **Generates strict types** from your content. **IDE autocompletion** and **compile-time errors** catch typos and missing keys before deployment.
 
   </Column>
+
 </Columns>
 
 **Why it matters:** Strong typing shifts failures **left** (CI/build) instead of **right** (runtime).
 
----
-
 ## Missing translation handling
 
 **next-intl**
@@ -220,8 +205,6 @@ Here is an example of the impact of bundle size optimisation using `intlayer` in
 
 **Why it matters:** Catching gaps during build prevents “mystery strings” in production and aligns with strict release gates.
 
----
-
 ## Routing, middleware & URL strategy
 
 <Columns>
@@ -246,12 +229,11 @@ Here is an example of the impact of bundle size optimisation using `intlayer` in
 - All of the above, plus **i18n middleware** (locale detection via headers/cookies) and **helpers** to generate localised URLs and `<link rel="alternate" hreflang="…">` tags.
 
   </Column>
+
 </Columns>
 
 **Why it matters:** Fewer custom glue layers; **consistent UX** and **clean SEO** across locales.
 
----
-
 ## Server Components (RSC) alignment
 
 <Columns>
@@ -276,12 +258,11 @@ Here is an example of the impact of bundle size optimisation using `intlayer` in
 - Supports Next.js 13+ and smooths the **server/client boundary** with a consistent API and RSC-oriented providers, avoiding shuttling formatters or t-functions.
 
   </Column>
+
 </Columns>
 
 **Why it matters:** Cleaner mental model and fewer edge cases in hybrid trees.
 
----
-
 ## Integration with localisation platforms (TMS)
 
 Large organisations often rely on Translation Management Systems (TMS) like **Crowdin**, **Phrase**, **Lokalise**, **Localizely**, or **Localazy**.
@@ -788,8 +769,6 @@ const ClientComponentExample = () => {
   - **next-intl** is flexible; load messages however you configure.
   - **Intlayer** stores content in TS/JS dictionaries and resolves by key.
 
----
-
 ### Usage in a server component
 
 We will take the case of a UI component. This component is a server component, and should be able to be inserted as a child of a client component. (page (server component) -> client component -> server component). As this component can be inserted as a child of a client component, it cannot be async.
@@ -889,7 +868,7 @@ Here is a list of best practices regarding multilingual SEO.
 Developers often forget to properly reference their pages across locales.
 
 <Tabs defaultTab="next-intl" group='techno'>
- 
+
   <Tab label="next-i18next" value="next-i18next">
 
 ```ts fileName="i18n.config.ts"
@@ -1147,8 +1126,6 @@ export default robots;
 
 > Intlayer provides a `getMultilingualUrls` function to generate multilingual URLs for your sitemap.
 
----
-
 ### Middleware for locale routing
 
 <Tabs defaultTab="next-intl" group='techno'>
@@ -1266,9 +1243,8 @@ The setup of the middleware is centralised in the `intlayer.config.ts` file.
 - **Integrated tooling**: Take advantage of built-in routing, SEO helpers, and visual editor support.
 
   </Tab>
-</Tabs>
 
----
+</Tabs>
 
 ## And the winner is…
 
@@ -1296,6 +1272,7 @@ It’s not simple. Each option has trade-offs. Here’s how I see it:
 - built for modern Next.js, with modular content, type safety, tooling, and less boilerplate. If you value **component-scoped content**, **strict TypeScript**, **build-time guarantees**, **tree-shaking**, and **batteries-included** routing/SEO/editor tooling – especially for **Next.js App Router**, design systems and **large, modular codebases**.
 
   </Column>
+
 </Columns>
 
 If you prefer minimal setup and accept some manual wiring, next-intl is a good choice. If you need all the features and don’t mind complexity, next-i18next works. But if you want a modern, scalable, modular solution with built-in tools, Intlayer aims to provide that out of the box.
@@ -1310,8 +1287,6 @@ GitHub stars are a strong indicator of a project's popularity, community trust,
 
 [![Star History Chart](https://api.star-history.com/chart?repos=i18next/next-i18next%2Camannn/next-intl%2Caymericzip/intlayer&type=date&legend=top-left)](https://www.star-history.com/#i18next/next-i18next&amannn/next-intl&aymericzip/intlayer)
 
----
-
 ## Conclusion
 
 All three libraries succeed at core localisation. The difference is **how much work you must do** to achieve a robust, scalable setup in **modern Next.js**:

package/blog/en-GB/nextjs-multilingual-seo-comparison.md

@@ -26,8 +26,6 @@ If your multilingual Next.js app doesn’t tell search engines how to crawl and
 
 In this blog, we’ll explore **why i18n is an SEO superpower** and how to implement it correctly in Next.js with `next-intl`, `next-i18next`, and `Intlayer`.
 
----
-
 ## Why SEO and i18n
 
 Adding languages isn’t just about UX. It’s also a powerful lever for **organic visibility**. Here’s why:
@@ -37,8 +35,6 @@ Adding languages isn’t just about UX. It’s also a powerful lever for **organ
 3. **Better UX:** Visitors land on the right version of your site immediately.
 4. **Competitive advantage:** Few sites implement multilingual SEO well which means you can stand out.
 
----
-
 ## Best Practices for Multilingual SEO in Next.js
 
 Here’s a checklist every multilingual app should implement:
@@ -57,8 +53,6 @@ Here’s a checklist every multilingual app should implement:
 
 These are simple steps, but skipping them can cost you visibility.
 
----
-
 ## Implementation Examples
 
 Developers often forget to properly reference their pages across locales so let’s look at how this works in practice with different libraries.
@@ -341,14 +335,10 @@ export default robots;
   </Tab>
 </Tabs>
 
----
-
 ## Audit your website with the Intlayer SEO Scanner
 
 To ensure your multilingual app is perfectly optimised, we recommend using the [Intlayer SEO Scanner](https://intlayer.org/i18n-seo-scanner). It is a specialised tool for multilingual website checking, helping you identify missing hreflang tags, broken links, and other SEO issues across all your localised pages.
 
----
-
 ## Conclusion
 
 Getting i18n right in Next.js isn’t just about translating text, it’s about making sure search engines and users know exactly which version of your content to serve.

package/blog/en-GB/rag_powered_documentation_assistant.md

@@ -71,7 +71,6 @@ At a high level, here’s the recipe I used:
 6.  **Logging queries for feedback** Every user query is stored. This is invaluable for understanding pain points, missing documentation, or new opportunities.
 
 <Steps>
-
 <Step number={1} title="Reading the Docs">
 
 The first step was straightforward: I needed a way to scan a docs/ folder for all .md files. Using Node.js and glob, I fetched the content of each Markdown file into memory.
@@ -79,7 +78,6 @@ The first step was straightforward: I needed a way to scan a docs/ folder for
 This keeps the pipeline flexible: instead of Markdown, you could fetch docs from a database, a CMS, or even an API.
 
 </Step>
-
 <Step number={2} title="Chunking the Documentation">
 
 Why chunk? Because language models have **context limits**. Feeding them an entire book of docs won’t work.
@@ -99,7 +97,6 @@ This trade-off (chunk size vs overlap) is key for RAG efficiency:
 - Too large → you blow up context size.
 
 </Step>
-
 <Step number={3} title="Generating Embeddings">
 
 Once the docs are chunked, we generate **embeddings**, high-dimensional vectors representing each chunk.
@@ -119,7 +116,6 @@ I used OpenAI’s text-embedding-3-large model, but you could use any modern e
 Each vector is a mathematical fingerprint of the text, enabling similarity search.
 
 </Step>
-
 <Step number={4} title="Indexing & Storing Embeddings">
 
 To avoid regenerating embeddings multiple times, I stored them in embeddings.json.
@@ -134,7 +130,6 @@ In production, you’d likely want a vector database such as:
 Vector DBs handle indexing, scalability, and fast search. But for my prototype, a local JSON worked fine.
 
 </Step>
-
 <Step number={5} title="Retrieval with Cosine Similarity">
 
 When a user asks a question:
@@ -148,7 +143,6 @@ Cosine similarity measures the angle between two vectors. A perfect match scores
 This way, the system finds the closest doc passages to the query.
 
 </Step>
-
 <Step number={6} title="Augmentation + Generation">
 
 Now comes the magic. We take the top chunks and inject them into the **system prompt** for ChatGPT.
@@ -158,7 +152,6 @@ That means the model answers as if those chunks were part of the conversation.
 The result: accurate, **doc-grounded responses**.
 
 </Step>
-
 <Step number={7} title="Logging User Queries">
 
 This is the hidden superpower.
@@ -173,7 +166,6 @@ Every question asked is stored. Over time, you build a dataset of:
 This turns your RAG assistant into a **continuous user research tool**.
 
 </Step>
-
 <Step number={8} title="What Does It Cost?">
 
 One common objection to RAG is cost. In practice, it’s surprisingly cheap:
@@ -185,7 +177,6 @@ One common objection to RAG is cost. In practice, it’s surprisingly cheap:
 On top of that, you can include the hosting cost.
 
 </Step>
-
 <Step number={9} title="Implementation Details">
 
 Stack:
@@ -251,7 +242,6 @@ We experimented with gpt-5, but latency was too high (sometimes up to 15 seconds
 👉 [Try the demo here](https://intlayer.org/doc/why) 👉 [Check the code template on GitHub](https://github.com/aymericzip/smart_doc_RAG)
 
 </Step>
-
 <Step number={10} title="Going Further">
 
 This project is a minimal implementation. But you can extend it in many ways:
@@ -265,7 +255,6 @@ This project is a minimal implementation. But you can extend it in many ways:
 - Improved prompting → reranking, filtering, and hybrid search (keyword + semantic)
 
 </Step>
-
 <Step number={11} title="Limitations We Hit">
 
 - Chunking and overlap are empirical. The right balance (chunk size, overlap percentage, number of retrieved chunks) requires iteration and testing.
@@ -273,7 +262,6 @@ This project is a minimal implementation. But you can extend it in many ways:
 - In this prototype, embeddings are stored in JSON. This works for demos but pollutes Git. In production, a database or dedicated vector store is preferable.
 
 </Step>
-
 <Step number={12} title="Why This Matters Beyond Docs">
 
 The interesting part is not just the chatbot. It’s the **feedback loop**.

package/blog/en-GB/react-i18next_vs_react-intl_vs_intlayer.md

@@ -37,16 +37,12 @@ We evaluate:
 
 > **tl;dr**: All three can localise a React app. If you want **component-scoped content**, **strict TypeScript types**, **build-time missing-key checks**, **tree-shaken dictionaries**, and built-in editorial tooling (Visual Editor/CMS + optional AI translation), **Intlayer** is the most complete choice for modular React codebases.
 
----
-
 ## High-level positioning
 
 - **react-intl** - ICU-first, standards-aligned formatting (dates/numbers/plurals) with a mature API. Catalogues are typically centralised; key safety and build-time validation are largely your responsibility.
 - **react-i18next** - Extremely popular and flexible; namespaces, detectors, and many plugins (ICU, backends). Powerful, but configuration can become sprawling as projects scale.
 - **Intlayer** - Component-centric content model for React, **strict TS typing**, **build-time checks**, **tree-shaking**, plus **Visual Editor/CMS** and **AI-assisted translations**. Works with React Router, Vite, CRA, etc.
 
----
-
 ## Feature matrix (React focus)
 
 | Feature                                       | `react-intlayer` (Intlayer)                                                                                                         | `react-i18next` (i18next)                                                                                | `react-intl` (FormatJS)                                                                     |
@@ -71,8 +67,6 @@ We evaluate:
 | **Purge unused content**                      | ✅ Yes, per-dictionary at build time                                                                                                | ❌ No, only via manual namespace segmentation                                                            | ❌ No, all declared messages are bundled                                                    |
 | **Management of Large Projects**              | ✅ Encourages modularity, suited for design systems                                                                                 | ⚠️ Requires good file discipline                                                                         | ⚠️ Central catalogues can become large                                                      |
 
----
-
 ## Deep-dive comparison
 
 ### 1) Architecture & scalability
@@ -82,8 +76,6 @@ We evaluate:
 
 **Why it matters:** Modular content mirrors modular UI. Large React codebases remain cleaner when translations reside with the components they belong to.
 
----
-
 ### 2) TypeScript & safety
 
 - **react-intl**: Solid typings, but **no automatic key typing**; you enforce safety patterns yourself.
@@ -92,8 +84,6 @@ We evaluate:
 
 **Why it matters:** Shifting failures **left** (to build/CI) reduces production issues and speeds developer feedback loops.
 
----
-
 ### 3) Missing translation handling
 
 - **react-intl / react-i18next**: Default to **runtime fallbacks** (key echo or default locale). You can add linting/plugins, but it’s not guaranteed at build.
@@ -101,8 +91,6 @@ We evaluate:
 
 **Why it matters:** CI failing on missing strings prevents “mystery English” leaking into non-English UIs.
 
----
-
 ### 4) Rich content & formatting
 
 - **react-intl**: Excellent **ICU** support for plurals, selects, dates/numbers, and message composition. JSX can be used, but the mental model remains message-centric.
@@ -111,8 +99,6 @@ We evaluate:
 
 **Why it matters:** Complex UI texts (links, bold sections, inline components) are easier when the library embraces React nodes cleanly.
 
----
-
 ### 5) Performance & loading behaviour
 
 - **react-intl / react-i18next**: You typically manage **catalogue splitting** and **lazy loading** manually (namespaces/dynamic imports). Effective but requires discipline.
@@ -120,8 +106,6 @@ We evaluate:
 
 **Why it matters:** Smaller bundles and fewer unused strings improve startup and navigation performance.
 
----
-
 ### 6) DX, tooling & maintenance
 
 - **react-intl / react-i18next**: Broad community ecosystem; for editorial workflows you usually adopt external localisation platforms.
@@ -129,24 +113,18 @@ We evaluate:
 
 **Why it matters:** Built-in tooling shortens the loop between developers and content authors - less glue code, fewer vendor dependencies.
 
----
-
 ## When to choose which?
 
 - **Choose react-intl** if you want **ICU-first** message formatting with a straightforward, standards-aligned API and your team is comfortable maintaining catalogues and safety checks manually.
 - **Choose react-i18next** if you need the **breadth of i18next’s ecosystem** (detectors, backends, ICU plugin, integrations) and accept more configuration to gain flexibility.
 - **Choose Intlayer** if you value **component-scoped content**, **strict TypeScript**, **build-time guarantees**, **tree-shaking**, and **batteries-included** editorial tooling - especially for **large, modular** React apps, design-systems, etc.
 
----
-
 ## Interoperability with `react-intl` and `react-i18next`
 
 `intlayer` can also help to manage your `react-intl` and `react-i18next` namespaces.
 
 Using `intlayer`, you can declare your content in the format of your favourite 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.