@intlayer/docs 7.2.2 → 7.3.0-canary.0

package/blog/tr/intlayer_with_next-i18next.md

@@ -187,7 +187,6 @@ Oluşturulan dosyaları sürüm kontrolünden hariç tutun:
 ```plaintext fileName=".gitignore"
 # Intlayer tarafından oluşturulan dosyaları yoksay
 .intlayer
-intl
 ```
 
 Bu dosyalar derleme sürecinde otomatik olarak yeniden oluşturulur ve depoza gönderilmesine gerek yoktur.

package/blog/tr/intlayer_with_vue-i18n.md

@@ -166,7 +166,6 @@ Oluşturulan dosyaları sürüm kontrolünden hariç tutun:
 ```plaintext fileName=".gitignore"
 # Intlayer tarafından oluşturulan dosyaları yoksay
 .intlayer
-intl
 ```
 
 Bu dosyalar derleme sürecinde otomatik olarak yeniden oluşturulur ve depoza gönderilmesine gerek yoktur.

package/blog/vi/compiler_vs_declarative_i18n.md

@@ -0,0 +1,138 @@
+---
+createdAt: 2025-11-24
+updatedAt: 2025-11-24
+title: Trình Biên Dịch so với i18n Khai Báo
+description: Khám phá các đánh đổi kiến trúc giữa quốc tế hóa dựa trên trình biên dịch "ma thuật" và quản lý nội dung khai báo rõ ràng.
+keywords:
+  - Intlayer
+  - Quốc tế hóa
+  - Blog
+  - Next.js
+  - JavaScript
+  - React
+  - i18n
+  - Trình Biên Dịch
+  - Khai Báo
+slugs:
+  - compiler-vs-declarative-i18n
+  - blog
+  - i18n
+---
+
+# Lập Luận Ủng Hộ và Phản Đối i18n Dựa Trên Trình Biên Dịch
+
+Nếu bạn đã xây dựng các ứng dụng web hơn một thập kỷ, bạn sẽ biết rằng Quốc tế hóa (i18n) luôn là một điểm gây khó khăn. Đây thường là công việc không ai muốn làm — trích xuất chuỗi, quản lý các tệp JSON, và lo lắng về các quy tắc số nhiều.
+
+Gần đây, một làn sóng mới các công cụ i18n "dựa trên trình biên dịch" đã xuất hiện, hứa hẹn sẽ làm biến mất những khó khăn này. Lời mời gọi thật hấp dẫn: **Chỉ cần viết văn bản trong các component của bạn, và để công cụ build lo phần còn lại.** Không cần khóa, không cần import, chỉ đơn giản là ma thuật.
+
+Nhưng như với tất cả các trừu tượng trong kỹ thuật phần mềm, ma thuật luôn đi kèm với một cái giá.
+
+Trong bài blog này, chúng ta sẽ khám phá sự chuyển dịch từ các thư viện khai báo sang các phương pháp dựa trên trình biên dịch, những khoản nợ kiến trúc ẩn mà chúng mang lại, và lý do tại sao cách "nhàm chán" có thể vẫn là cách tốt nhất cho các ứng dụng chuyên nghiệp.
+
+## Lịch Sử Ngắn Gọn về Dịch Thuật
+
+Để hiểu chúng ta đang ở đâu, chúng ta phải nhìn lại nơi chúng ta đã bắt đầu.
+
+Khoảng năm 2011–2012, cảnh quan JavaScript rất khác biệt. Các bundler như chúng ta biết ngày nay (Webpack, Vite) chưa tồn tại hoặc còn trong giai đoạn sơ khai. Chúng ta phải dán các script lại với nhau ngay trong trình duyệt. Trong thời kỳ này, các thư viện như **i18next** đã ra đời.
+
+Chúng giải quyết vấn đề theo cách duy nhất có thể vào thời điểm đó: **Từ điển thời gian chạy (Runtime Dictionaries)**. Bạn tải một đối tượng JSON khổng lồ vào bộ nhớ, và một hàm sẽ tra cứu các khóa ngay lập tức. Cách này đáng tin cậy, rõ ràng và hoạt động ở mọi nơi.
+
+Tiến tới ngày nay. Chúng ta có các trình biên dịch mạnh mẽ (SWC, các bundler dựa trên Rust) có thể phân tích Cây Cú Pháp Trừu Tượng (AST) trong vài mili giây. Sức mạnh này đã sinh ra một ý tưởng mới: _Tại sao chúng ta phải quản lý khóa thủ công? Tại sao trình biên dịch không thể nhìn thấy đoạn văn bản "Hello World" và thay thế nó cho chúng ta?_
+
+Và thế là i18n dựa trên trình biên dịch ra đời.
+
+## Sức Hấp Dẫn của Trình Biên Dịch (Cách Tiếp Cận "Phép Thuật")
+
+Có một lý do khiến cách tiếp cận mới này đang trở thành xu hướng. Đối với một nhà phát triển, trải nghiệm này thật tuyệt vời.
+
+### 1. Tốc Độ và "Dòng Chảy"
+
+Khi bạn đang tập trung, việc dừng lại để nghĩ tên biến (`home_hero_title_v2`) sẽ làm gián đoạn dòng chảy công việc của bạn. Với cách tiếp cận trình biên dịch, bạn chỉ cần gõ `<p>Welcome back</p>` và tiếp tục. Không có sự cản trở nào.
+
+### 2. Nhiệm Vụ Cứu Hộ Di Sản
+
+Hãy tưởng tượng bạn thừa kế một codebase khổng lồ với 5.000 component và không có bản dịch nào. Việc bổ sung hệ thống dựa trên khóa thủ công sẽ là một cơn ác mộng kéo dài hàng tháng. Công cụ dựa trên trình biên dịch hoạt động như một chiến lược cứu hộ, ngay lập tức trích xuất hàng ngàn chuỗi mà bạn không cần phải chạm vào bất kỳ file nào thủ công.
+
+### 3. Thời Đại AI
+
+Đây là một lợi ích hiện đại mà chúng ta không nên bỏ qua. Các trợ lý lập trình AI (như Copilot hoặc ChatGPT) tự nhiên tạo ra JSX/HTML tiêu chuẩn. Chúng không biết sơ đồ khóa dịch thuật cụ thể của bạn.
+
+- **Khai báo:** Bạn phải viết lại đầu ra của AI để thay thế văn bản bằng các khóa.
+- **Trình biên dịch:** Bạn chỉ cần sao chép-dán mã của AI, và nó hoạt động ngay.
+
+## Kiểm Tra Thực Tế: Tại Sao "Phép Thuật" Lại Nguy Hiểm
+
+Mặc dù "phép thuật" rất hấp dẫn, nhưng sự trừu tượng này lại bị rò rỉ. Dựa vào công cụ xây dựng để hiểu ý định của con người sẽ tạo ra sự mong manh về kiến trúc.
+
+### 1. Sự Mong Manh Dựa Trên Phán Đoán (Trò Chơi Đoán)
+
+Trình biên dịch phải đoán đâu là nội dung và đâu là mã.
+
+- `className="active"` có được dịch không? Nó là một chuỗi.
+- `status="pending"` có được dịch không?
+- Có phải `<MyComponent errorMessage="An error occurred" />` được dịch không?
+- Có phải một ID sản phẩm như `"AX-99"` được dịch không?
+
+Bạn không thể tránh khỏi việc "đấu tranh" với trình biên dịch, thêm các chú thích cụ thể (như `// ignore-translation`) để ngăn nó phá vỡ logic ứng dụng của bạn.
+
+### 2. Giới Hạn Cứng của Dữ Liệu Động
+
+Việc trích xuất của trình biên dịch dựa trên **phân tích tĩnh**. Nó phải nhìn thấy chuỗi ký tự nguyên văn trong mã của bạn để tạo ra một ID ổn định.
+Nếu API của bạn trả về một chuỗi mã lỗi như `server_error`, bạn không thể dịch nó bằng trình biên dịch vì trình biên dịch không biết chuỗi đó tồn tại tại thời điểm xây dựng. Bạn buộc phải xây dựng một hệ thống "chỉ chạy thời gian thực" phụ trợ chỉ dành cho dữ liệu động.
+
+### 3. "Bùng Nổ Chunk" và Hiện Tượng Thác Nước Mạng
+
+Để cho phép tree-shaking, các công cụ trình biên dịch thường chia nhỏ bản dịch theo từng component.
+
+- **Hệ quả:** Một trang hiển thị với 50 component nhỏ có thể kích hoạt **50 yêu cầu HTTP riêng biệt** cho các đoạn dịch nhỏ. Ngay cả với HTTP/2, điều này tạo ra một chuỗi yêu cầu mạng khiến ứng dụng của bạn cảm thấy chậm chạp so với việc tải một gói ngôn ngữ duy nhất được tối ưu hóa.
+
+### 4. Chi phí hiệu năng khi chạy
+
+Để làm cho bản dịch phản ứng (để chúng cập nhật ngay lập tức khi bạn chuyển đổi ngôn ngữ), trình biên dịch thường chèn các hook quản lý trạng thái vào _mọi_ component.
+
+- **Chi phí:** Nếu bạn render một danh sách gồm 5.000 mục, bạn sẽ khởi tạo 5.000 hook `useState` và `useEffect` chỉ để xử lý văn bản. Điều này tiêu tốn bộ nhớ và chu kỳ CPU mà các thư viện khai báo (thường sử dụng một Context provider duy nhất) có thể tiết kiệm được.
+
+## Cái bẫy: Bị khóa nhà cung cấp
+
+Đây có thể coi là khía cạnh nguy hiểm nhất của i18n dựa trên trình biên dịch.
+
+Trong một thư viện khai báo, mã nguồn của bạn chứa ý định rõ ràng. Bạn sở hữu các khóa. Nếu bạn chuyển đổi thư viện, bạn chỉ cần thay đổi phần import.
+
+Trong cách tiếp cận dựa trên trình biên dịch, **mã nguồn của bạn chỉ là văn bản tiếng Anh.** "Logic dịch thuật" chỉ tồn tại bên trong cấu hình plugin xây dựng.
+Nếu thư viện đó ngừng được duy trì, hoặc nếu bạn vượt quá khả năng của nó, bạn sẽ bị mắc kẹt. Bạn không thể dễ dàng "eject" vì bạn không có bất kỳ khóa dịch nào trong mã nguồn của mình. Bạn sẽ phải tự tay viết lại toàn bộ ứng dụng để di chuyển sang giải pháp khác.
+
+## Mặt khác: Rủi ro của phương pháp khai báo
+
+Công bằng mà nói, cách khai báo truyền thống cũng không hoàn hảo. Nó có những "cạm bẫy" riêng.
+
+1.  **Địa ngục Namespace:** Bạn thường phải quản lý thủ công các tệp JSON nào sẽ được tải (`common.json`, `dashboard.json`, `footer.json`). Nếu bạn quên một tệp, người dùng sẽ thấy các khóa thô.
+2.  **Tải quá mức:** Nếu không cấu hình cẩn thận, rất dễ vô tình tải _tất cả_ các khóa dịch của bạn cho _tất cả_ các trang ngay lần tải đầu tiên, làm phình to kích thước gói của bạn.
+3.  **Trôi đồng bộ:** Thông thường các khóa vẫn còn trong file JSON dù component sử dụng chúng đã bị xóa. Các file dịch của bạn sẽ ngày càng phình to, chứa đầy các "khóa ma."
+
+## Giải pháp Trung gian của Intlayer
+
+Đây là nơi các công cụ như **Intlayer** cố gắng đổi mới. Intlayer hiểu rằng dù compiler rất mạnh mẽ, nhưng phép thuật ngầm lại nguy hiểm.
+
+Intlayer cung cấp một **lệnh `transform`** độc đáo. Thay vì chỉ làm phép thuật trong bước build ẩn, nó thực sự có thể **viết lại mã component của bạn**. Nó quét văn bản và thay thế bằng các khai báo nội dung rõ ràng trong codebase của bạn.
+
+Điều này mang lại cho bạn lợi ích của cả hai thế giới:
+
+1.  **Độ chi tiết:** Bạn giữ bản dịch gần với các component của mình (cải thiện tính mô-đun và tree-shaking).
+2.  **An toàn:** Bản dịch trở thành mã rõ ràng, không phải là phép thuật ẩn trong thời gian build.
+3.  **Không bị khóa:** Vì mã được chuyển đổi thành cấu trúc khai báo tiêu chuẩn trong repo của bạn, bạn không giấu logic trong một plugin webpack.
+
+## Kết luận
+
+Vậy, bạn nên chọn gì?
+
+**Nếu bạn là một Junior Developer, một Nhà sáng lập đơn lẻ, hoặc đang xây dựng MVP:**
+Phương pháp dựa trên compiler là một lựa chọn hợp lệ. Nó cho phép bạn di chuyển cực kỳ nhanh. Bạn không cần phải lo lắng về cấu trúc file hay các khóa. Bạn chỉ cần xây dựng. Nợ kỹ thuật là vấn đề của "Bạn trong tương lai."
+
+**Nếu bạn đang xây dựng một Ứng dụng Chuyên nghiệp, Cấp Doanh nghiệp:**
+Phép thuật thường là một ý tưởng tồi. Bạn cần kiểm soát.
+
+- Bạn cần xử lý dữ liệu động từ backend.
+- Bạn cần đảm bảo hiệu suất trên các thiết bị cấu hình thấp (tránh hiện tượng hook bị quá tải).
+- Bạn cần đảm bảo rằng bạn không bị khóa vào một công cụ build cụ thể mãi mãi.
+
+Đối với các ứng dụng chuyên nghiệp, **Quản lý Nội dung Khai báo** (như Intlayer hoặc các thư viện đã được thiết lập) vẫn là tiêu chuẩn vàng. Nó tách biệt các mối quan tâm của bạn, giữ cho kiến trúc của bạn sạch sẽ, và đảm bảo rằng khả năng đa ngôn ngữ của ứng dụng không phụ thuộc vào một trình biên dịch "hộp đen" đoán ý định của bạn.

package/blog/vi/intlayer_with_next-i18next.md

@@ -176,7 +176,6 @@ Loại trừ các file được tạo tự động khỏi việc kiểm soát ph
 ```plaintext fileName=".gitignore"
 # Bỏ qua các file được tạo bởi Intlayer
 .intlayer
-intl
 ```
 
 Các file này được tự động tạo lại trong quá trình build và không cần phải commit vào kho mã của bạn.

package/blog/vi/intlayer_with_vue-i18n.md

@@ -166,7 +166,6 @@ Loại trừ các tệp được tạo tự động khỏi kiểm soát phiên b
 ```plaintext fileName=".gitignore"
 # Bỏ qua các tệp được tạo bởi Intlayer
 .intlayer
-intl
 ```
 
 Các tệp này được tạo lại tự động trong quá trình xây dựng và không cần phải cam kết vào kho lưu trữ của bạn.

package/blog/zh/compiler_vs_declarative_i18n.md

@@ -0,0 +1,138 @@
+---
+createdAt: 2025-11-24
+updatedAt: 2025-11-24
+title: 编译器与声明式国际化的对比
+description: 探讨“魔法”编译器驱动国际化与显式声明式内容管理之间的架构权衡。
+keywords:
+  - Intlayer
+  - 国际化
+  - 博客
+  - Next.js
+  - JavaScript
+  - React
+  - i18n
+  - 编译器
+  - 声明式
+slugs:
+  - compiler-vs-declarative-i18n
+  - blog
+  - i18n
+---
+
+# 支持与反对编译器驱动国际化的观点
+
+如果你从事网页应用开发超过十年，你会知道国际化（i18n）一直是一个难点。它通常是没人愿意做的任务——提取字符串、管理 JSON 文件，以及处理复数规则。
+
+最近，一波新的“编译器驱动”国际化工具出现了，承诺让这份痛苦消失。它们的卖点很诱人：**只需在组件中编写文本，构建工具会处理剩下的一切。**无需键名，无需导入，纯粹是魔法。
+
+但正如软件工程中的所有抽象一样，魔法是有代价的。
+
+在这篇博客文章中，我们将探讨从声明式库向编译器驱动方法的转变，它们引入的隐藏架构债务，以及为什么“无聊”的方式可能仍然是专业应用的最佳选择。
+
+## 翻译的简史
+
+要理解我们现在的位置，必须回顾我们从哪里开始。
+
+大约在2011年至2012年，JavaScript的生态环境截然不同。我们现在熟知的打包工具（如Webpack、Vite）当时还不存在或处于初期阶段。那时，我们是在浏览器中将脚本拼接在一起。在那个时代，像**i18next**这样的库诞生了。
+
+它们以当时唯一可行的方式解决了问题：**运行时字典**。你将一个庞大的JSON对象加载到内存中，然后通过函数动态查找键。它可靠、明确，并且在任何地方都能工作。
+
+快进到今天。我们拥有强大的编译器（如SWC、基于Rust的打包工具），能够在毫秒级别解析抽象语法树（AST）。这种能力催生了一个新想法：_为什么我们还要手动管理键？为什么编译器不能直接看到文本“Hello World”并替我们替换它？_
+
+于是，基于编译器的i18n诞生了。
+
+## 编译器的魅力（“魔法”方法）
+
+这种新方法之所以流行是有原因的。对于开发者来说，这种体验令人难以置信。
+
+### 1. 速度与“流畅感”
+
+当你进入状态时，停下来思考一个变量名（如 `home_hero_title_v2`）会打断你的思路。使用编译器方法时，你只需输入 `<p>Welcome back</p>`，然后继续前进。摩擦为零。
+
+### 2. 旧代码救援任务
+
+想象一下，继承了一个拥有5000个组件且没有任何翻译的大型代码库。用手动基于键的系统来改造它，将是一场持续数月的噩梦。基于编译器的工具则像一场救援行动，能够瞬间提取成千上万的字符串，而你无需手动触碰任何文件。
+
+### 3. AI 时代
+
+这是一个我们不应忽视的现代优势。AI 编码助手（如 Copilot 或 ChatGPT）自然生成标准的 JSX/HTML。它们并不知道你特定的翻译键方案。
+
+- **声明式（Declarative）：** 你必须重写 AI 的输出，将文本替换为键。
+- **编译器（Compiler）：** 你只需复制粘贴 AI 的代码，它就能直接工作。
+
+## 现实检验：为什么“魔法”是危险的
+
+虽然“魔法”很吸引人，但抽象层会泄漏。依赖构建工具去理解人类意图会引入架构上的脆弱性。
+
+### 1. 启发式脆弱性（猜测游戏）
+
+编译器必须猜测什么是内容，什么是代码。
+
+- `className="active"` 会被翻译吗？它是一个字符串。
+- `status="pending"` 会被翻译吗？
+- `<MyComponent errorMessage="An error occurred" />` 会被翻译吗？
+- 像 `"AX-99"` 这样的产品 ID 会被翻译吗？
+
+你不可避免地会与编译器“斗争”，添加特定注释（如 `// ignore-translation`）以防止它破坏你的应用逻辑。
+
+### 2. 动态数据的硬性限制
+
+编译器提取依赖于**静态分析**。它必须在代码中看到字面字符串才能生成稳定的 ID。
+如果你的 API 返回一个错误代码字符串，比如 `server_error`，你无法用编译器翻译它，因为编译器在构建时并不知道该字符串的存在。你被迫为动态数据构建一个次级的“仅运行时”系统。
+
+### 3. “块爆炸”和网络瀑布效应
+
+为了支持 tree-shaking，编译器工具通常会按组件拆分翻译内容。
+
+- **后果：** 一个页面视图中如果有 50 个小组件，可能会触发 **50 个独立的 HTTP 请求** 来获取微小的翻译片段。即使使用 HTTP/2，这也会造成网络瀑布效应，使你的应用相比加载单个优化语言包时显得响应迟缓。
+
+### 4. 运行时性能开销
+
+为了让翻译具有响应性（以便切换语言时能即时更新），编译器通常会在 _每个_ 组件中注入状态管理钩子。
+
+- **代价：** 如果你渲染一个包含5000个条目的列表，你实际上是在为文本初始化5000个 `useState` 和 `useEffect` 钩子。这会消耗大量内存和CPU周期，而声明式库（通常只使用一个 Context 提供者）则能节省这些资源。
+
+## 陷阱：供应商锁定
+
+这可以说是基于编译器的国际化中最危险的方面。
+
+在声明式库中，你的源代码包含明确的意图。你拥有翻译键。如果你切换库，只需更改导入即可。
+
+而在基于编译器的方法中，**你的源代码只是英文文本。** “翻译逻辑”仅存在于构建插件的配置中。
+如果该库停止维护，或者你超出了它的能力范围，你就会陷入困境。你无法轻易“弹出”，因为你的源代码中没有任何翻译键。你必须手动重写整个应用程序才能迁移。
+
+## 另一面：声明式方法的风险
+
+公平地说，传统的声明式方法也并不完美。它有自己的一些“坑”。
+
+1.  **命名空间地狱：** 你经常需要手动管理加载哪些 JSON 文件（如 `common.json`、`dashboard.json`、`footer.json`）。如果忘记加载其中一个，用户就会看到原始的键名。
+2.  **过度获取：** 如果配置不当，很容易在初始加载时意外加载所有页面的所有翻译键，导致包体积膨胀。
+3.  **同步漂移（Sync Drift）：** 通常情况下，某些键会在对应组件被删除很久之后仍然保留在 JSON 文件中。你的翻译文件会无限增长，充满了“僵尸键”。
+
+## Intlayer 的折中方案
+
+这正是像 **Intlayer** 这样的工具试图创新的地方。Intlayer 理解编译器虽然强大，但隐式的魔法是危险的。
+
+Intlayer 提供了一个独特的 **`transform` 命令**。它不仅仅是在隐藏的构建步骤中做魔法，而是可以实际**重写你的组件代码**。它扫描你的文本，并用显式的内容声明替换代码库中的文本。
+
+这让你同时拥有两者的优点：
+
+1.  **粒度控制（Granularity）：** 你可以将翻译内容保持在组件附近（提升模块化和 tree-shaking 效果）。
+2.  **安全性：** 翻译变成了显式代码，而不是隐藏的构建时魔法。
+3.  **无锁定：** 由于代码被转换为仓库内的标准声明式结构，你不会将逻辑隐藏在 webpack 插件中。
+
+## 结论
+
+那么，你应该选择哪种方案？
+
+**如果你是初级开发者、独立创始人，或者正在构建 MVP：**  
+基于编译器的方法是一个有效的选择。它允许你非常快速地开发。你无需担心文件结构或键值。你只需构建。技术债务是“未来的你”的问题。
+
+**如果你正在构建专业的企业级应用：**  
+魔法通常不是一个好主意。你需要掌控。
+
+- 你需要处理来自后端的动态数据。
+- 您需要确保在低端设备上的性能（避免钩子爆炸）。
+- 您需要确保不会永远被锁定在特定的构建工具中。
+
+对于专业应用，**声明式内容管理**（如 Intlayer 或成熟的库）仍然是黄金标准。它将关注点分离，保持架构清晰，并确保您的应用多语言能力不依赖于“黑盒”编译器去猜测您的意图。

package/blog/zh/intlayer_with_next-i18next.md

@@ -176,7 +176,6 @@ export default config;
 ```plaintext fileName=".gitignore"
 # 忽略 Intlayer 生成的文件
 .intlayer
-intl
 ```
 
 这些文件会在构建过程中自动重新生成，无需提交到您的代码仓库。

package/blog/zh/intlayer_with_vue-i18n.md

@@ -166,7 +166,6 @@ export default config;
 ```plaintext fileName=".gitignore"
 # 忽略 Intlayer 生成的文件
 .intlayer
-intl
 ```
 
 这些文件会在构建过程中自动重新生成，无需提交到您的代码仓库。

package/dist/cjs/generated/blog.entry.cjs

@@ -24,6 +24,25 @@ const readLocale = (relativeAfterLocale, locale) => {
 	return Promise.reject(/* @__PURE__ */ new Error(`[docs] File not found: ${relativeAfterLocale} - locale: ${locale} - path: ${target1} - path: ${target2}`));
 };
 const blogEntry = {
+	"./blog/en/compiler_vs_declarative_i18n.md": {
+		en: readLocale("compiler_vs_declarative_i18n.md", "en"),
+		ru: readLocale("compiler_vs_declarative_i18n.md", "ru"),
+		ja: readLocale("compiler_vs_declarative_i18n.md", "ja"),
+		fr: readLocale("compiler_vs_declarative_i18n.md", "fr"),
+		ko: readLocale("compiler_vs_declarative_i18n.md", "ko"),
+		zh: readLocale("compiler_vs_declarative_i18n.md", "zh"),
+		es: readLocale("compiler_vs_declarative_i18n.md", "es"),
+		de: readLocale("compiler_vs_declarative_i18n.md", "de"),
+		ar: readLocale("compiler_vs_declarative_i18n.md", "ar"),
+		it: readLocale("compiler_vs_declarative_i18n.md", "it"),
+		"en-GB": readLocale("compiler_vs_declarative_i18n.md", "en-GB"),
+		pt: readLocale("compiler_vs_declarative_i18n.md", "pt"),
+		hi: readLocale("compiler_vs_declarative_i18n.md", "hi"),
+		tr: readLocale("compiler_vs_declarative_i18n.md", "tr"),
+		pl: readLocale("compiler_vs_declarative_i18n.md", "pl"),
+		id: readLocale("compiler_vs_declarative_i18n.md", "id"),
+		vi: readLocale("compiler_vs_declarative_i18n.md", "vi")
+	},
 	"./blog/en/i18n_using_next-i18next.md": {
 		en: readLocale("i18n_using_next-i18next.md", "en"),
 		ru: readLocale("i18n_using_next-i18next.md", "ru"),