@intlayer/docs 9.0.0-canary.4 → 9.0.0-canary.5

package/docs/ar/packages/react-intlayer/useDictionary.md

@@ -24,102 +24,6 @@ history:
 author: aymericzip
 ---
 
-# تكامل React: توثيق هوك `useDictionary`
-
-يوفر هذا القسم إرشادات مفصلة حول استخدام هوك `useDictionary` داخل تطبيقات React، مما يتيح إدارة فعالة للمحتوى المحلي بدون محرر بصري.
-
-## استيراد `useDictionary` في React
-
-يمكن دمج هوك `useDictionary` في تطبيقات React عن طريق استيراده بناءً على السياق:
-
-- **مكون العميل:**
-
-  ```typescript codeFormat="typescript"
-  import { useDictionary } from "react-intlayer"; // يستخدم في مكونات React على جانب العميل
-  ```
-
-  ```javascript codeFormat="esm"
-  import { useDictionary } from "react-intlayer"; // يستخدم في مكونات React على جانب العميل
-  ```
-
-  ```javascript codeFormat="commonjs"
-  const { useDictionary } = require("react-intlayer"); // يستخدم في مكونات React على جانب العميل
-  ```
-
-- **مكون الخادم:**
-
-  ```typescript codeFormat="typescript"
-  import { useDictionary } from "react-intlayer/server"; // يستخدم في مكونات React على جانب الخادم
-  ```
-
-  ```javascript codeFormat="esm"
-  import { useDictionary } from "react-intlayer/server"; // يستخدم في مكونات React على جانب الخادم
-  ```
-
-  ```javascript codeFormat="commonjs"
-  const { useDictionary } = require("react-intlayer/server"); // يستخدم في مكونات React على جانب الخادم
-  ```
-
-## المعاملات
-
-يقبل الهوك معاملين:
-
-1. **`dictionary`**: كائن قاموس معلن يحتوي على محتوى محلي لمفاتيح محددة.
-2. **`locale`** (اختياري): اللغة المطلوبة. الافتراضي هو لغة السياق الحالي إذا لم يتم تحديدها.
-
-## القاموس
-
-يجب إعلان جميع كائنات القاموس في ملفات محتوى منظمة لضمان سلامة الأنواع ومنع أخطاء وقت التشغيل. يمكنك العثور على [تعليمات الإعداد هنا](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ar/dictionary/content_file.md). إليك مثال على إعلان المحتوى:
-
-```typescript fileName="./component.content.ts" contentDeclarationFormat={["typescript", "esm", "commonjs"]}
-import { t, type Dictionary } from "intlayer";
-
-const componentContent = {
-  key: "component-example",
-  content: {
-    title: t({
-      en: "Client Component Example",
-      fr: "Exemple de composant client",
-      es: "Ejemplo de componente cliente",
-    }),
-    content: t({
-      en: "This is the content of a client component example",
-      fr: "Ceci est le contenu d'un exemple de composant client",
-      es: "Este es el contenido de un ejemplo de componente cliente",
-    }),
-  },
-} satisfies Dictionary;
-
-export default componentContent;
-```
-
-```json fileName="./component.content.json" contentDeclarationFormat="json"
-{
-  "$schema": "https://intlayer.org/schema.json",
-  "key": "component-example",
-  "content": {
-    "title": {
-      "nodeType": "translation",
-      "translation": {
-        "ar": "مثال على مكون العميل",
-        "en": "Client Component Example",
-        "fr": "Exemple de composant client",
-        "es": "Ejemplo de componente cliente"
-      }
-    },
-    "content": {
-      "nodeType": "translation",
-      "translation": {
-        "ar": "هذا هو محتوى مثال على مكون العميل",
-        "en": "This is the content of a client component example",
-        "fr": "Ceci est le contenu d'un exemple de composant client",
-        "es": "Este es el contenido de un ejemplo de componente cliente"
-      }
-    }
-  }
-}
-```
-
 ## مثال على الاستخدام في React
 
 فيما يلي مثال على كيفية استخدام الخطاف `useDictionary` في مكون React:
@@ -162,14 +66,6 @@ const ServerComponentExample: FC<{ locale: string }> = ({ locale }) => {
 };
 ```
 
-## ملاحظات حول السمات
-
-على عكس التكاملات التي تستخدم المحررات المرئية، فإن السمات مثل `buttonTitle.value` لا تنطبق هنا. بدلاً من ذلك، قم بالوصول مباشرة إلى السلاسل المحلية كما هو معلن في المحتوى الخاص بك.
-
-```jsx
-<button title={content.title}>{content.content}</button>
-```
-
 ## نصائح إضافية
 
 - **سلامة النوع**: استخدم دائمًا `Dictionary` لتعريف القواميس الخاصة بك لضمان سلامة النوع.

package/docs/ar/packages/react-intlayer/useI18n.md

@@ -142,7 +142,3 @@ const ServerComponentExample = () => {
 - **محرر Intlayer المرئي**: للحصول على تجربة إدارة محتوى أكثر سهولة وبديهية، راجع توثيق المحرر المرئي [هنا](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ar/intlayer_visual_editor.md).
 
 يغطي هذا القسم بشكل خاص دمج الخطاف `useI18n` في تطبيقات React، مما يبسط عملية التعريب ويضمن اتساق المحتوى عبر اللغات المختلفة.
-
-## تاريخ التوثيق
-
-- 6.0.0 - 2025-06-29: الكتابة الأولية لتوثيق الخطاف `useI18n`

package/docs/ar/packages/react-intlayer/useIntlayer.md

@@ -21,49 +21,6 @@ slugs:
 author: aymericzip
 ---
 
-# تكامل React: توثيق هوك `useIntlayer`
-
-يوفر هذا القسم إرشادات مفصلة حول استخدام هوك `useIntlayer` داخل تطبيقات React، مما يتيح تعريب المحتوى بكفاءة.
-
-## استيراد `useIntlayer` في React
-
-يمكن دمج هوك `useIntlayer` في تطبيقات React عن طريق استيراده بناءً على السياق:
-
-- **مكون العميل:**
-
-  ```typescript codeFormat="typescript"
-  import { useIntlayer } from "react-intlayer"; // يُستخدم في مكونات React على جانب العميل
-  ```
-
-  ```javascript codeFormat="esm"
-  import { useIntlayer } from "react-intlayer"; // يُستخدم في مكونات React على جانب العميل
-  ```
-
-  ```javascript codeFormat="commonjs"
-  const { useIntlayer } = require("react-intlayer"); // يُستخدم في مكونات React على جانب العميل
-  ```
-
-- **مكون الخادم:**
-
-  ```typescript codeFormat="commonjs"
-  import { useIntlayer } from "react-intlayer/server"; // يُستخدم في مكونات React على جانب الخادم
-  ```
-
-  ```javascript codeFormat="esm"
-  import { useIntlayer } from "react-intlayer/server"; // يُستخدم في مكونات React على جانب الخادم
-  ```
-
-  ```javascript codeFormat="commonjs"
-  const { useIntlayer } = require("react-intlayer/server"); // يُستخدم في مكونات React على جانب الخادم
-  ```
-
-## المعاملات
-
-يقبل الـ hook معاملين:
-
-1. **`key`**: مفتاح القاموس لاسترجاع المحتوى المحلي.
-2. **`locale`** (اختياري): اللغة المطلوبة. القيمة الافتراضية هي لغة السياق إذا لم يتم تحديدها.
-
 ## القاموس
 
 يجب إعلان جميع مفاتيح القاموس داخل ملفات إعلان المحتوى لتعزيز أمان النوع وتجنب الأخطاء. يمكنك العثور على [تعليمات الإعداد هنا](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ar/dictionary/content_file.md).
@@ -127,20 +84,8 @@ const ServerComponentExample = () => {
 };
 ```
 
-## التعامل مع السمات
-
-عند تعريب السمات، قم بالوصول إلى قيم المحتوى بشكل مناسب:
-
-```jsx
-<button title={content.buttonTitle.value}>{content.buttonText}</button>
-```
-
 ## موارد إضافية
 
 - **محرر Intlayer المرئي**: لتجربة إدارة محتوى أكثر سهولة وبديهية، راجع توثيق المحرر المرئي [هنا](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ar/intlayer_visual_editor.md).
 
 تستهدف هذه القسم بشكل خاص دمج الخطاف `useIntlayer` في تطبيقات React، مما يبسط عملية التعريب ويضمن تناسق المحتوى عبر اللغات المختلفة.
-
-## تاريخ التوثيق
-
-- 5.5.10 - 2025-06-29: بداية السجل

package/docs/ar/releases/v6.md

@@ -25,6 +25,10 @@ author: aymericzip
 
 مرحبًا بك في Intlayer v6! يركز هذا الإصدار على الأداء، تجربة المطور، والموثوقية. فيما يلي أبرز النقاط، مع ملاحظات الترحيل وأمثلة قابلة للنسخ واللصق.
 
+## جدول المحتويات
+
+<TOC levels={[2]} maxDepth={1} />
+
 ## أبرز النقاط
 
 - أمر جديد: `npx intlayer content test` لاكتشاف الترجمات المفقودة
@@ -294,6 +298,24 @@ bun x intlayer live --with 'vite preview'
 
 ---
 
+## عملية متوازية لمراقبة الملفات على turbopack
+
+عند استخدام Turbopack على Next.js 14 وما فوق كخادم التطوير الخاص بك مع أمر `next dev --turbopack`، لن يتم اكتشاف تغييرات القاموس تلقائياً بشكل افتراضي.
+
+يحدث هذا التحديد لأن Turbopack لا يمكنه تشغيل مكونات webpack بالتوازي لمراقبة التغييرات في ملفات المحتوى الخاصة بك.
+
+للعمل حول هذا، أسقطنا أمر `intlayer watch`، باستخدام خيار `--with` لتشغيل كل من خادم التطوير ومراقب بناء Intlayer في نفس الوقت.
+
+```json5 fileName="package.json"
+{
+  "scripts": {
+    "dev": "npx intlayer watch --with 'next dev --turbopack'",
+  },
+}
+```
+
+---
+
 ## ملاحظات الترحيل
 
 - تمت الإزالة: `dictionaryOutput` (كان يُستخدم سابقًا مع `i18next` أو `next-intl`). سيعود هذا كموصلات قابلة للإضافة في الإصدارات المستقبلية. قم بإزالة هذا الحقل من تكوينك.
@@ -312,6 +334,12 @@ bun x intlayer live --with 'vite preview'
 
 ---
 
+## ملاحظات الترحيل من v6 إلى v7
+
+تحقق من [ملاحظات الترحيل من v6 إلى v7](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ar/releases/v7.md) للمزيد من المعلومات.
+
+---
+
 ## روابط مفيدة
 
 - [مرجع CLI](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ar/cli/index.md)

package/docs/ar/releases/v7.md

@@ -25,6 +25,10 @@ author: aymericzip
 
 مرحبًا بك في Intlayer v7! يقدم هذا الإصدار الكبير تحسينات ملحوظة في الأداء، أمان الأنواع، وتجربة المطور. فيما يلي أبرز النقاط، مع ملاحظات الترحيل وأمثلة عملية.
 
+## جدول المحتويات
+
+<TOC levels={[2]} maxDepth={1} />
+
 ## أبرز النقاط
 
 - استراتيجية التخزين المؤقت لبناء أسرع
@@ -260,6 +264,126 @@ setLocale("en");
 
 ---
 
+## تنسيق الكود التلقائي: تكوين formatCommand
+
+يقدم الإصدار v7 خيار `formatCommand` في تكوين المحرر، مما يسمح لك بتنسيق ملفات المحتوى تلقائياً عند كتابتها بواسطة Intlayer. وهذا يضمن أسلوب كود متسق وتنسيق موحد عبر ملفات إعلان المحتوى الخاصة بك.
+
+إذا لم يتم تعيينه، سيحاول Intlayer الكشف عن أمر التنسيق تلقائياً. من خلال محاولة حل الأوامر التالية: prettier, biome, eslint.
+
+### الإعدادات
+
+تقبل خيار `formatCommand` قالب نص حيث سيتم استبدال `{{file}}` بمسار الملف الفعلي:
+
+```typescript fileName="intlayer.config.ts"
+export default {
+  content: {
+    formatCommand: 'bun x biome format "{{file}}" --write --log-level none',
+  },
+};
+```
+
+### منسقات مدعومة
+
+يمكنك استخدام أي منسق أكواد يقبل مسارات الملفات كمعاملات:
+
+**باستخدام Biome:**
+
+```typescript
+formatCommand: 'bun x biome format "{{file}}" --write --log-level none';
+```
+
+**باستخدام Prettier:**
+
+```typescript
+formatCommand: 'npx prettier --write "{{file}}" --log-level silent';
+```
+
+**باستخدام ESLint:**
+
+```typescript
+formatCommand: 'npx eslint --fix "{{file}}" --quiet';
+```
+
+**باستخدام منسق Bun المدمج:**
+
+```typescript
+formatCommand: 'bun format "{{file}}"';
+```
+
+### الفوائد
+
+- **تنسيق متسق**: يتم تنسيق جميع ملفات المحتوى تلقائياً وفقاً لإرشادات نمط مشروعك
+- **تجربة المطور**: لا حاجة لتنسيق الملفات يدوياً بعد كتابة Intlayer لها
+- **اتساق الفريق**: يضمن أن جميع أعضاء الفريق لديهم نفس التنسيق المطبق على ملفات المحتوى
+- **تكامل CI/CD**: تحافظ ملفات المحتوى على تنسيق متسق في سير العمل الآلي
+
+### كيف يعمل
+
+عندما يكتب Intlayer أو يحدث ملف إعلان محتوى (`.content.ts`، `.content.js`، إلخ)، فإنه يقوم تلقائياً بتشغيل أمر التنسيق المحدد على الملف. يتم استبدال العنصر النائب `{{file}}` بمسار الملف الفعلي، ويتم تنفيذ الأمر في دليل قاعدة المشروع.
+
+---
+
+## تكوين القاموس: تنظيم وهيكلة أفضل
+
+يقدم الإصدار v7 قسم تكوين `dictionary` مخصصًا جديدًا يوفر تنظيمًا أفضل لإعدادات القاموس وإدارة محسنة للمحتوى.
+
+### هيكل تكوين القاموس الجديد
+
+تم نقل خاصية `fill` من قسم `content` إلى قسم `dictionary` جديد، مما يوفر فصلاً أوضح للمسؤوليات:
+
+**تكوين v6:**
+
+```typescript fileName="intlayer.config.ts"
+export default {
+  content: {
+    autoFill: "./{{fileName}}.content.json",
+    contentDir: ["src"],
+  },
+};
+```
+
+**تكوين v7:**
+
+```typescript fileName="intlayer.config.ts"
+export default {
+  content: {
+    contentDir: ["src"],
+  },
+  dictionary: {
+    fill: "./{{fileName}}.content.json",
+  },
+};
+```
+
+### فوائد الهيكل الجديد
+
+- **تنظيم أوضح**: يتم الآن تجميع الإعدادات الخاصة بالقاموس معًا
+- **فصل أفضل للاهتمامات**: يتم فصل اكتشاف المحتوى عن عمليات القاموس بوضوح
+- **قابلية صيانة محسّنة**: يسهل فهم وتعديل التكوينات المتعلقة بالقاموس
+- **قابلية التوسع في المستقبل**: يمكن لقسم القاموس أن يستوعب إعدادات إضافية خاصة بالقاموس
+- **إدارة قاموس شاملة**: تتضمن خصائص مثل `title` و `live` و `priority` و `tags` و `version` و `description` لإنشاء وإدارة قواميس جديدة
+
+### استخدام التكوين
+
+يخدم تكوين القاموس غرضين رئيسيين:
+
+1. **القيم الافتراضية**: تحديد القيم الافتراضية عند إنشاء ملفات إعلان المحتوى
+2. **سلوك الرجوع**: توفير قيم بديلة عندما لا يتم تحديد حقول معينة، مما يسمح لك بتحديد سلوك تشغيل القاموس بشكل عام
+
+يتضمن قسم القاموس خصائص شاملة لإدارة القاموس:
+
+- **`fill`**: سلوك الملء التلقائي لإنشاء المحتوى
+- **`title`**: العنوان الافتراضي للقواميیس الجديدة
+- **`live`**: تكوين المزامنة الحية للتحديثات في الوقت الفعلي
+- **`priority`**: إعدادات الأولویة لحل القاموس
+- **`tags`**: الوسوم الافتراضية لتنظيم المحتوى
+- **`version`**: إدارة الإصدار لتحديثات القاموس
+- **`description`**: الوصف الافتراضي للمحتوى الجديد
+
+للمزید من المعلومات حول ملفات إعلان المحتوى وكيف يتم تطبيق قيم التكوين، راجع [توثيق ملف المحتوى](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ar/dictionary/content_file.md).
+
+---
+
 ## أمر fill: سلوك محدث لإدارة محتوى أفضل
 
 يقدم الإصدار 7 سلوكًا محسّنًا لأمر `fill`، مما يوفر إدارة محتوى أكثر توقعًا ومرونة:
@@ -407,6 +531,10 @@ const content = {
 - **`middleware.prefixDefault`**: تم استبداله بـ `routing.mode`
 - **`middleware.noPrefix`**: تم استبداله بـ `routing.mode`
 
+### تكوينات جديدة
+
+- **`editor.formatCommand`**: خيار جديد لتنسيق الكود تلقائياً لملفات المحتوى
+
 ### خريطة الترحيل
 
 #### خريطة التهيئة

package/docs/ar/releases/v9.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-06-14
-updatedAt: 2026-06-14
+updatedAt: 2026-06-23
 title: Intlayer v9 الجديد - ما الجديد؟
 description: اكتشف ما هو جديد في Intlayer v9. نقدم حزم توافق جاهزة للاستخدام لمكتبات i18n الشهيرة ودعمًا للمجموعات (Collections) والمتغيرات (Variants) والسجلات الديناميكية (Dynamic Records).
 keywords:
@@ -216,6 +216,42 @@ export default {
 
 ---
 
+## Vite Plugin: Bundled Compiler & Proxy
+
+يجمع plugin `intlayer()` Vite الآن **المترجم** و**بروكسي التوجيه حسب اللغة** مباشرة، لذا تحتاج معظم المشاريع إلى plugin واحد فقط في `vite.config.ts`:
+
+```ts fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import { intlayer } from "vite-intlayer";
+
+export default defineConfig({
+  plugins: [intlayer()],
+});
+```
+
+- **Compiler**: يتم التفعيل تلقائياً عندما يتم ضبط `compiler.enabled` وتكوين مسار `compiler.output`. لا تحتاج إلى تسجيل `intlayerCompiler()` بشكل منفصل بعد الآن.
+- **Proxy**: يتم التفعيل تلقائياً بناءً على خيار `routing.enableProxy` الجديد (`true` افتراضياً). يوصل middleware الكشف عن اللغة / إعادة التوجيه / إعادة الكتابة في التطوير والمعاينة وإنتاج SSR. لا تحتاج إلى تسجيل `intlayerProxy()` بشكل منفصل بعد الآن.
+
+### خيار `routing.enableProxy`
+
+خيار `routing.enableProxy` جديد يتحكم في ما إذا كان proxy التوجيه الخاص باللغة متصلاً. القيمة الافتراضية هي `true`. قم بتعطيله عندما تريد التعامل مع توجيه اللغة بنفسك:
+
+```ts fileName="intlayer.config.ts"
+import type { IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  routing: {
+    enableProxy: false, // الافتراضي: true
+  },
+};
+
+export default config;
+```
+
+تبقى plugins `intlayerCompiler()` و `intlayerProxy()` المستقلة مُصدَّرة للإعدادات المتقدمة. تسجيلها جنباً إلى جنب مع `intlayer()` آمن — كل plugin يزيل التكرار عن نفسه ويعمل مرة واحدة فقط.
+
+---
+
 ## ملاحظات الترحيل من الإصدار 8
 
 إذا كنت تقوم بالترقية من الإصدار 8، لاحظ أن الإصدار 9 لا يتضمن تغييرات جذرية (breaking changes). ولكن إليك التغييرات الرئيسية:

package/docs/ar/roadmap.md

@@ -28,6 +28,12 @@ Intlayer هو حل لإدارة المحتوى والتدويل مصمم لتب
 
 ---
 
+## جدول المحتويات
+
+<TOC/>
+
+---
+
 ## الميزات الحالية
 
 ### 1. إعلان المحتوى

package/docs/de/CI_CD.md

@@ -26,6 +26,10 @@ author: aymericzip
 
 Intlayer ermöglicht die automatische Generierung von Übersetzungen für Ihre Content-Deklarationsdateien. Es gibt verschiedene Möglichkeiten, dies je nach Ihrem Workflow zu realisieren.
 
+## Inhaltsverzeichnis
+
+<TOC/>
+
 ## Verwendung des CMS
 
 Mit Intlayer können Sie einen Workflow verwenden, bei dem nur eine einzige Locale lokal deklariert wird, während alle Übersetzungen remote über das CMS verwaltet werden. Dies ermöglicht es, Inhalte und Übersetzungen vollständig von der Codebasis zu trennen, bietet mehr Flexibilität für Content-Editoren und ermöglicht ein Hot Content Reloading (kein erneutes Bauen der Anwendung erforderlich, um Änderungen anzuwenden).

package/docs/de/autoFill.md

@@ -28,6 +28,53 @@ history:
 author: aymericzip
 ---
 
+# Füllen Sie Content Declaration File Translations aus
+
+**Autofill content declaration files** in Ihrer CI sind eine Möglichkeit, Ihren Entwicklungs-Workflow zu beschleunigen.
+
+## Das Verhalten verstehen
+
+Der `fill`-Befehl umfasst zwei Modi:
+
+- **Complete**: Füllt automatisch alle fehlenden Inhalte für jedes Locale aus und bearbeitet die aktuelle Datei oder eine andere angegebene Datei. Das heißt, der Complete-Modus überspringt die Übersetzung bereits vorhandener Inhalte, falls diese bereits übersetzt wurden.
+- **Review**: Füllt automatisch **alle** Inhalte für jedes Locale aus und generiert für eine bestimmte Datei oder eine andere angegebene Datei.
+
+Der `fill`-Befehl verarbeitet alle Ihre Locale-Content-Deklarationsdateien. Das heißt, er verarbeitet nicht Ihre Remote-Inhalte aus dem CMS. Das CMS umfasst sein eigenes Übersetzungsverwaltungssystem.
+Wenn Sie Plugins wie `@intlayer/sync-json-plugin` verwenden, wird Intlayer die JSON-Dateien in Locale-Content-Deklarationsdateien umwandeln. Das heißt, sie werden vom `fill`-Befehl verarbeitet.
+
+Die neu generierten Dateien enthalten eine `filled`-Anweisung als Dictionary-Metadaten. Diese Anweisung wird von Intlayer verwendet, um zu erkennen, ob die Datei automatisch ausgefüllt wurde oder nicht, und überspringt diese Datei, falls vorhanden, vor erneuter Übersetzung.
+
+Intlayer berücksichtigt auch die folgende Anweisung zum automatischen Ausfüllen:
+
+- Aus Ihrer `.content.{ts|js|json}` → `fill`-Anweisung
+- Aus Ihrer Konfigurationsdatei `.intlayer.config.ts` → `dictionary.fill`-Anweisung
+- Wird standardmäßig auf `true` gesetzt, ansonsten
+
+Bei Pro-Locale-Content-Deklarationsdateien wird die `true`-Anweisung durch `./{{fileName}}.fill.content.json` ersetzt. Dies ist der Fall, da eine Pro-Locale-Content-Deklarationsdatei keine zusätzlichen lokalisierten Inhalte erhalten kann. Daher wird eine neue Datei generiert, um die vorhandene Datei nicht zu überschreiben.
+
+## Standardverhalten
+
+Standardmäßig ist `fill` global auf `true` eingestellt, was bedeutet, dass Intlayer automatisch alle Content-Dateien ausfüllt und die Datei selbst bearbeitet. Dieses Verhalten kann auf verschiedene Weise angepasst werden:
+
+### Globale Konfigurationsoptionen
+
+1. **`fill: true` (Standard)** - Füllt automatisch alle Locales aus und bearbeitet die aktuelle Datei
+2. **`fill: false`** - Deaktiviert das automatische Ausfüllen für diese Content-Datei
+3. **`fill: "./relative/path/to/file"`** - Erstellt/aktualisiert die angegebene Datei, ohne die aktuelle zu bearbeiten, indem auf einen relativen Pfad verwiesen wird, der basierend auf dem Speicherort der aktuellen Datei aufgelöst wird
+4. **`fill: "/absolute/path/to/file"`** - Erstellt/aktualisiert die angegebene Datei, ohne die aktuelle zu bearbeiten, indem auf einen relativen Pfad verwiesen wird, der basierend auf dem Speicherort des Basisverzeichnisses aufgelöst wird (Feld `baseDir` in der Konfigurationsdatei `.intlayer.config.ts`)
+5. **`fill: "C:\\absolute\path\to\file"`** - Erstellt/aktualisiert die angegebene Datei, ohne die aktuelle zu bearbeiten, indem auf einen absoluten Pfad verwiesen wird, der basierend auf Ihrem Betriebssystem aufgelöst wird
+6. **`fill: { [key in Locales]?: string }`** - Erstellt/aktualisiert die angegebene Datei für jede Locale
+
+### v7 Behavior Changes
+
+In v7 hat sich das Verhalten des `fill`-Befehls aktualisiert:
+
+- **`fill: true`** - Schreibt die aktuelle Datei mit gefülltem Inhalt für alle Locales um
+- **`fill: "path/to/file"`** - Füllt die angegebene Datei, ohne die aktuelle Datei zu ändern
+- **`fill: false`** - Deaktiviert Auto-Fill vollständig
+
+Bei Verwendung einer Path-Option zum Schreiben in eine andere Datei funktioniert der Fill-Mechanismus über eine _Master-Slave_-Beziehung zwischen Content-Declaration-Dateien. Die Hauptdatei (Master) dient als Single Source of Truth, und wenn sie aktualisiert wird, wendet Intlayer diese Änderungen automatisch auf die abgeleiteten (gefüllten) Declaration-Dateien an, die durch den Path angegeben werden.
+
 # Übersetzungen der Deklarationsdatei für automatisches Ausfüllen von Inhalten
 
 **Deklarationsdateien für automatisches Ausfüllen von Inhalten** sind eine Möglichkeit, Ihren Entwicklungsworkflow zu beschleunigen.
@@ -88,6 +135,40 @@ Intlayer generiert automatisch die abgeleitete Deklarationsdatei unter `src/comp
 
 Anschließend werden beide Deklarationsdateien zu einem einzigen Wörterbuch zusammengeführt, das über den Standard-`useIntlayer("example")` Hook (React) / Composable (Vue) zugänglich ist.
 
+## Globale Konfiguration
+
+Sie können die globale Auto-Fill-Konfiguration in der Datei `intlayer.config.ts` konfigurieren.
+
+```ts fileName="intlayer.config.ts"
+import { type IntlayerConfig, Locales } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+    requiredLocales: [Locales.ENGLISH, Locales.FRENCH],
+  },
+  dictionary: {
+    // Fehlende Übersetzungen automatisch für alle Wörterbücher generieren
+    fill: "./{{fileName}}Filled.content.ts",
+    //
+    // fill: "/messages/{{locale}}/{{key}}/{{fileName}}.content.json",
+    //
+    // fill: true, // Fehlende Übersetzungen automatisch für alle Wörterbücher generieren wie die Verwendung von "./{{fileName}}.content.json"
+    //
+    // fill: {
+    //   en: "./{{fileName}}.en.content.json",
+    //   fr: "./{{fileName}}.fr.content.json",
+    //   es: "./{{fileName}}.es.content.json",
+    // },
+  },
+};
+
+export default config;
+```
+
+Sie können die Konfiguration pro Wörterbuch noch optimieren, indem Sie das Feld `fill` in Content-Dateien verwenden. Intlayer berücksichtigt zunächst die Pro-Wörterbuch-Konfiguration und fällt dann auf die globale Konfiguration zurück.
+
 ## Automatisch ausgefülltes Dateiformat
 
 Das empfohlene Format für automatisch ausgefüllte Deklarationsdateien ist **JSON**, da es Formatierungsbeschränkungen vermeidet. Intlayer unterstützt jedoch auch `.ts`, `.js`, `.mjs`, `.cjs` und andere Formate.

package/docs/de/benchmark/solid.md

@@ -118,6 +118,28 @@ Wir haben **vier Ladestrategien** verglichen:
 - **Scoped static**: Hält den Code organisiert (logische Trennung) ohne komplexe zusätzliche Netzwerkanfragen.
 - **Scoped dynamic**: Bester Ansatz für _Code-Splitting_ und Leistung. Minimiert den Speicherverbrauch, indem nur das geladen wird, was die aktuelle Ansicht und die aktive Locale benötigen.
 
+### Was ich gemessen habe:
+
+Ich habe dieselbe mehrsprachige App in einem echten Browser für jeden Stack ausgeführt und dann notiert, was tatsächlich übertragen wurde und wie lange es dauerte. Größen werden **nach normaler Web-Komprimierung** gemeldet, da dies näher an dem liegt, was Benutzer herunterladen, als an rohen Quellzählungen.
+
+- **Internationalization-Bibliotheksgröße**: Nach dem Bundling, Tree-Shaking und Minifizierung ist die Größe der i18n-Bibliothek die Größe der Provider + Hooks/Primitives-Code in einer leeren Komponente. Sie beinhaltet nicht das Laden von Übersetzungsdateien. Sie antwortet darauf, wie teuer die Bibliothek ist, bevor Ihr Inhalt ins Spiel kommt.
+
+- **JavaScript pro Seite**: Für jede Benchmark-Route, wie viel Skript der Browser bei diesem Besuch abruft, gemittelt über die Seiten in der Suite (und über Sprachen, wenn der Bericht sie zusammenfasst). Schwere Seiten sind langsame Seiten.
+
+- **Leakage von anderen Sprachen**: Es ist der Inhalt derselben Seite, aber in einer anderen Sprache, die versehentlich auf der überprüften Seite geladen würde. Dieser Inhalt ist unnötig und sollte vermieden werden. (z. B. Inhalt der Seite `/fr/about` im Bundle `/en/about`)
+
+- **Leakage von anderen Routes**: Die gleiche Idee für **andere Bildschirme** in der App: ob ihr Text mitlädt, wenn Sie nur eine Seite öffnen. (z. B. Inhalt der Seite `/en/about` im Bundle `/en/contact`). Eine hohe Punktzahl deutet auf schwache Aufteilung oder zu breite Bundles hin.
+
+- **Durchschnittliche Komponenten-Bundle-Größe**: Häufige UI-Elemente werden **einzeln** gemessen, anstatt sich in einer großen App-Nummer zu verstecken. Es zeigt, ob die Internationalisierung alltägliche Komponenten stillschweigend aufbläht. Wenn beispielsweise Ihre Komponente neu gerendert wird, lädt sie alle diese Daten aus dem Speicher. Das Anhängen eines großen JSON an eine Komponente ist wie das Verbinden mit einem großen Speicher von ungenutzten Daten, die die Leistung Ihrer Komponenten verlangsamen.
+
+- **Responsivität beim Sprachenwechsel**: Ich wechsle die Sprache mit dem eigenen Steuerelement der App und messe, wie lange es dauert, bis die Seite deutlich gewechselt hat, was ein Besucher bemerken würde, nicht ein Lab-Micro-Schritt.
+
+- **Rendering-Arbeit nach einem Sprachenwechsel**: Eine engere Nachverfolgung: wie viel Aufwand die Schnittstelle brauchte, um für die neue Sprache neu zu zeichnen, sobald der Wechsel im Fluss ist. Nützlich, wenn sich die „gefühlte" Zeit und die Framework-Kosten unterscheiden.
+
+- **Anfängliche Seitenladezeit**: Von der Navigation bis der Browser die Seite für die getesteten Szenarien als vollständig geladen betrachtet. Gut für den Vergleich von Cold Starts.
+
+- **Hydration-Zeit**: Wenn die App es offenlegt, wie lange der Client damit verbringt, Server-HTML in etwas umzuwandeln, das Sie tatsächlich anklicken können. Ein Bindestrich in den Tabellen bedeutet, dass diese Implementierung in diesem Benchmark keine zuverlässige Hydration-Zahl lieferte.
+
 ## GitHub-Sterne
 
 GitHub-Sterne sind ein starker Indikator für die Popularität eines Projekts, das Vertrauen der Community und die langfristige Relevanz. Sie sind zwar kein direktes Maß für die technische Qualität, spiegeln jedoch wider, wie viele Entwickler das Projekt nützlich finden, seinen Fortschritt verfolgen und es wahrscheinlich übernehmen werden. Um den Wert eines Projekts einzuschätzen, helfen Sterne dabei, die Traktion verschiedener Alternativen zu vergleichen und Einblicke in das Wachstum des Ökosystems zu gewinnen.

package/docs/de/benchmark/svelte.md

@@ -116,6 +116,28 @@ Wir haben **vier Ladestrategien** verglichen:
 - **Scoped static**: Hält den Code organisiert (logische Trennung) ohne komplexe zusätzliche Netzwerkanfragen.
 - **Scoped dynamic**: Bester Ansatz für _Code-Splitting_ und Leistung. Minimiert den Speicherverbrauch, indem nur das geladen wird, was die aktuelle Ansicht und die aktive Locale benötigen.
 
+### Was ich gemessen habe:
+
+Ich habe dieselbe mehrsprachige App in einem echten Browser für jeden Stack ausgeführt und dann notiert, was tatsächlich auf der Leitung angezeigt wurde und wie lange es dauerte. Die Größen werden **nach normaler Webkomprimierung** angegeben, da dies näher daran liegt, was Benutzer herunterladen, als rohe Quellzählungen.
+
+- **Größe der Internationalisierungsbibliothek**: Nach dem Bundeln, Tree-Shaking und der Minifizierung ist die Größe der i18n-Bibliothek die Größe des Providers + Stores-Code in einer leeren Komponente. Sie beinhaltet nicht das Laden von Übersetzungsdateien. Sie beantwortet die Frage, wie teuer die Bibliothek ist, bevor Ihr Inhalt ins Spiel kommt.
+
+- **JavaScript pro Seite**: Für jede Benchmark-Route, wie viel Skript der Browser bei diesem Besuch abruft, gemittelt über die Seiten in der Suite (und über Sprachen, in denen der Bericht diese zusammenfasst). Schwere Seiten sind langsame Seiten.
+
+- **Speicherleck aus anderen Sprachen**: Es ist der Inhalt derselben Seite in einer anderen Sprache, der versehentlich auf die audited Seite geladen würde. Dieser Inhalt ist unnötig und sollte vermieden werden. (z. B. Inhalt der Seite `/fr/about` im Bundle der Seite `/en/about`)
+
+- **Speicherleck aus anderen Routen**: Dieselbe Idee für **andere Bildschirme** in der App: ob deren Kopie mitlädt, wenn Sie nur eine Seite geöffnet haben. (z. B. Inhalt der Seite `/en/about` im Bundle der Seite `/en/contact`). Ein hoher Wert deutet auf schwaches Splitting oder über-breite Bundles hin.
+
+- **Durchschnittliche Komponentenbündelgröße**: Häufige UI-Teile werden **einzeln** gemessen, anstatt sich in einer großen App-Nummer zu verstecken. Es zeigt, ob die Internationalisierung alltägliche Komponenten unauffällig aufbläht. Wenn Ihre Komponente beispielsweise neu gerendert wird, wird sie alle diese Daten aus dem Speicher laden. Das Anhängen eines großen JSON an eine Komponente ist wie das Verbinden mit einem großen Speicher ungenutzter Daten, der die Leistung Ihrer Komponenten verlangsamt.
+
+- **Sprachschalter-Reaktionsfähigkeit**: Ich wechsle die Sprache mit dem eigenen Steuerelement der App und messe, wie lange es dauert, bis sich die Seite klar gewechselt hat, was ein Besucher bemerken würde, nicht ein Lab-Mikro-Schritt.
+
+- **Rendering-Arbeit nach einem Sprachwechsel**: Ein engerer Nachfolger: wie viel Aufwand die Benutzeroberfläche brauchte, um sich für die neue Sprache neu zu streichen, sobald der Wechsel in Gang ist. Nützlich, wenn sich die „gefühlte" Zeit und die Framework-Kosten unterscheiden.
+
+- **Anfängliche Seitenladezeit**: Von der Navigation zum Browser, der die Seite für die von mir getesteten Szenarien vollständig geladen betrachtet. Gut zum Vergleichen kalter Starts.
+
+- **Hydrationisierungszeit**: Wenn die App es offenlegt, wie lange der Client damit verbringt, Server-HTML in etwas zu verwandeln, das Sie tatsächlich anklicken können. Ein Bindestrich in den Tabellen bedeutet, dass diese Implementierung in dieser Benchmark keine zuverlässige Hydrationsfigur bereitgestellt hat.
+
 ## GitHub-Sterne
 
 GitHub-Sterne sind ein starker Indikator für die Popularität eines Projekts, das Vertrauen der Community und die langfristige Relevanz. Sie sind zwar kein direktes Maß für die technische Qualität, spiegeln jedoch wider, wie viele Entwickler das Projekt nützlich finden, seinen Fortschritt verfolgen und es wahrscheinlich übernehmen werden. Um den Wert eines Projekts einzuschätzen, helfen Sterne dabei, die Traktion verschiedener Alternativen zu vergleichen und Einblicke in das Wachstum des Ökosystems zu gewinnen.