Intlayer

--- createdAt: 2025-01-02 updatedAt: 2025-06-29 title: react-i18next مقابل react-intl مقابل Intlayer description: دمج react-i18next مع next-intl و Intlayer للتدويل (i18n) في تطبيق React keywords: - next-intl - react-i18next - Intlayer - التدويل - مدونة - Next.js - جافا سكريبت - React slugs: - blog - react-i18next-vs-react-intl-vs-intlayer --- # react-Intl مقابل react-i18next مقابل intlayer | التدويل في React (i18n) تُقارن هذه الدليل بين ثلاثة خيارات معروفة للتدويل (i18n) لـ **React**: **react-intl** (FormatJS)، **react-i18next** (i18next)، و **Intlayer**. نركز على تطبيقات **React العادية** (مثل Vite، CRA، SPA). إذا كنت تستخدم Next.js، راجع مقارنة Next.js المخصصة لدينا. نقوم بتقييم: - البنية والتنظيم المحتوى - TypeScript والأمان - التعامل مع الترجمات المفقودة - المحتوى الغني وقدرات التنسيق - الأداء وسلوك التحميل - تجربة المطور (DX)، الأدوات والصيانة - تحسين محركات البحث/التوجيه (يعتمد على الإطار) > **ملخص**: يمكن لجميع الثلاثة تعريب تطبيق React. إذا كنت تريد **محتوى مخصص للمكون**، **أنواع TypeScript صارمة**، **فحوصات المفاتيح المفقودة أثناء البناء**، **قواميس معزولة بالشجرة (tree-shaken)**، وأدوات تحرير مدمجة (محرر بصري/نظام إدارة المحتوى + ترجمة مدعومة بالذكاء الاصطناعي اختيارية)، فإن **Intlayer** هو الخيار الأكثر تكاملاً لقواعد الشيفرة المعيارية في React. --- ## التموقع على مستوى عالٍ - **react-intl** - تنسيق يركز على ICU ومتوافق مع المعايير (تواريخ/أرقام/جمع) مع واجهة برمجة تطبيقات ناضجة. عادةً ما تكون الكتالوجات مركزية؛ سلامة المفاتيح والتحقق أثناء وقت البناء تقع إلى حد كبير على عاتقك. - **react-i18next** - شائع للغاية ومرن؛ يدعم المساحات الاسمية، والكاشفات، والعديد من الإضافات (ICU، الخلفيات). قوي، لكن التكوين قد يتوسع مع نمو المشاريع. - **Intlayer** - نموذج محتوى يركز على المكونات لـ React، **أنواع TypeScript صارمة**، **فحوصات أثناء وقت البناء**، **عزل بالشجرة (tree-shaking)**، بالإضافة إلى **محرر بصري/نظام إدارة محتوى** و**ترجمات مدعومة بالذكاء الاصطناعي**. يعمل مع React Router وVite وCRA، وغيرها. --- ## مصفوفة الميزات (تركيز على React) | الميزة | `react-intlayer` (Intlayer) | `react-i18next` (i18next) | `react-intl` (FormatJS) | | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | **الترجمات بالقرب من المكونات** | ✅ نعم، المحتوى موضوع بجانب كل مكون | ❌ لا | ❌ لا | | **تكامل TypeScript** | ✅ متقدم، أنواع صارمة مولدة تلقائيًا | ⚠️ أساسي؛ إعداد إضافي للسلامة | ✅ جيد، لكن أقل صرامة | | **كشف الترجمات المفقودة** | ✅ تمييز أخطاء TypeScript وتحذير/خطأ أثناء وقت البناء | ⚠️ غالبًا سلاسل احتياطية أثناء التشغيل | ⚠️ سلاسل احتياطية | | **المحتوى الغني (JSX/Markdown/مكونات)** | ✅ دعم مباشر | ⚠️ محدود / فقط التداخل | ⚠️ صيغة ICU، ليست JSX حقيقية | | **الترجمة المدعومة بالذكاء الاصطناعي** | ✅ نعم، يدعم مزودي ذكاء اصطناعي متعددين. يمكن استخدامه باستخدام مفاتيح API الخاصة بك. يأخذ في الاعتبار سياق تطبيقك ونطاق المحتوى | ❌ لا | ❌ لا | | **المحرر المرئي** | ✅ نعم، محرر مرئي محلي + نظام إدارة محتوى اختياري؛ يمكنه إخراج محتوى قاعدة الشيفرة؛ قابل للتضمين | ❌ لا / متوفر عبر منصات التوطين الخارجية | ❌ لا / متوفر عبر منصات التوطين الخارجية | | **التوجيه المحلي** | ✅ نعم، يدعم المسارات المحلية مباشرة (يعمل مع Next.js و Vite) | ⚠️ لا يوجد مدمج، يتطلب إضافات (مثل `next-i18next`) أو تكوين مخصص للموجه | ❌ لا، فقط تنسيق الرسائل، يجب أن يكون التوجيه يدويًا | | **توليد المسارات الديناميكية** | ✅ نعم | ⚠️ يتطلب إضافة/نظام بيئي أو إعداد يدوي | ❌ غير متوفر | | **التعددية** | ✅ أنماط قائمة على التعداد | ✅ قابلة للتكوين (إضافات مثل i18next-icu) | ✅ (ICU) | | **التنسيق (التواريخ، الأرقام، العملات)** | ✅ منسقات محسنة (Intl تحت الغطاء) | ⚠️ عبر إضافات أو استخدام Intl مخصص | ✅ منسقات ICU | | **تنسيق المحتوى** | ✅ .tsx, .ts, .js, .json, .md, .txt, (.yaml قيد العمل) | ⚠️ .json | ✅ .json, .js | | **دعم ICU** | ⚠️ قيد العمل | ⚠️ عبر إضافة (i18next-icu) | ✅ نعم | | **مساعدو تحسين محركات البحث (hreflang، خريطة الموقع)** | ✅ أدوات مدمجة: مساعدات لخريطة الموقع، robots.txt، البيانات الوصفية | ⚠️ إضافات مجتمعية/يدوية | ❌ ليست جزءًا أساسيًا | | **النظام البيئي / المجتمع** | ⚠️ أصغر لكن ينمو بسرعة وبشكل تفاعلي | ✅ الأكبر والأكثر نضجًا | ✅ كبير | | **التصيير على جانب الخادم ومكونات الخادم** | ✅ نعم، مُبسّط للتصيير على جانب الخادم / مكونات خادم React | ⚠️ مدعوم على مستوى الصفحة ولكن يحتاج لتمرير دوال t على شجرة المكونات لمكونات الخادم الفرعية | ❌ غير مدعوم، يحتاج لتمرير دوال t على شجرة المكونات لمكونات الخادم الفرعية | | **إزالة الشجر (تحميل المحتوى المستخدم فقط)** | ✅ نعم، لكل مكون أثناء وقت البناء عبر إضافات Babel/SWC | ⚠️ عادةً ما يحمل الكل (يمكن تحسينه باستخدام المساحات الاسمية/تقسيم الكود) | ⚠️ عادةً ما يحمل الكل | | **التحميل الكسول** | ✅ نعم، لكل لغة / لكل قاموس | ✅ نعم (مثل الخلفيات/المساحات الاسمية عند الطلب) | ✅ نعم (تقسيم حزم اللغة) | | **تنقية المحتوى غير المستخدم** | ✅ نعم، لكل قاموس أثناء وقت البناء | ❌ لا، فقط عبر تقسيم المساحات الاسمية يدويًا | ❌ لا، جميع الرسائل المعلنة يتم تجميعها | | **إدارة المشاريع الكبيرة** | ✅ يشجع على التصميم المعياري، مناسب لأنظمة التصميم | ⚠️ يحتاج إلى انضباط جيد في الملفات | ⚠️ يمكن أن تصبح الكتالوجات المركزية كبيرة | --- ## مقارنة متعمقة ### 1) البنية والقابلية للتوسع - **react-intl / react-i18next**: معظم الإعدادات تحافظ على **مجلدات لغة مركزية** لكل لغة، وأحيانًا مقسمة حسب **المساحات الاسمية** (i18next). يعمل بشكل جيد في البداية لكنه يصبح مساحة مشتركة مع نمو التطبيقات. - **Intlayer**: يعزز وجود **قواميس لكل مكون (أو لكل ميزة)** **متمركزة** مع واجهة المستخدم التي تخدمها. هذا يحافظ على وضوح الملكية، ويسهل تكرار/ترحيل المكونات، ويقلل من تقلب المفاتيح بين الفرق. من الأسهل تحديد المحتوى غير المستخدم وإزالته. **لماذا هذا مهم:** المحتوى المعياري يعكس واجهة المستخدم المعيارية. قواعد كود React الكبيرة تبقى أنظف عندما تعيش الترجمات مع المكونات التي تنتمي إليها. --- ### 2) TypeScript والأمان - **react-intl**: أنواع قوية، لكن **لا يوجد تعيين تلقائي للمفاتيح**؛ أنت من يفرض أنماط الأمان بنفسك. - **react-i18next**: أنواع قوية للخطافات؛ **التعيين الصارم للمفاتيح** عادة ما يتطلب تكوينًا إضافيًا أو مولدات. - **Intlayer**: **ينشئ تلقائيًا أنواعًا صارمة** من المحتوى الخاص بك. الإكمال التلقائي في بيئة التطوير و**أخطاء وقت الترجمة** تلتقط الأخطاء الإملائية والمفاتيح المفقودة قبل وقت التشغيل. **لماذا هذا مهم:** نقل الأخطاء إلى **المرحلة المبكرة** (أثناء البناء/التكامل المستمر) يقلل من مشاكل الإنتاج ويسرع دورات تغذية راجع المطورين. --- ### 3) التعامل مع الترجمات المفقودة - **react-intl / react-i18next**: تعتمد بشكل افتراضي على **الاستعانة بالبدائل وقت التشغيل** (تكرار المفتاح أو اللغة الافتراضية). يمكنك إضافة أدوات فحص/إضافات، لكنها ليست مضمونة أثناء البناء. - **Intlayer**: **الكشف أثناء البناء** مع تحذيرات أو أخطاء عند فقدان اللغات/المفاتيح المطلوبة. **لماذا هذا مهم:** فشل التكامل المستمر عند وجود سلاسل مفقودة يمنع تسرب "الإنجليزية الغامضة" إلى واجهات المستخدم غير الإنجليزية. --- ### 4) المحتوى الغني والتنسيق - **react-intl**: دعم ممتاز لـ **ICU** للجمع، والاختيارات، والتواريخ/الأرقام، وتركيب الرسائل. يمكن استخدام JSX، لكن النموذج الذهني يبقى مركزًا على الرسالة. - **react-i18next**: تعبير مرن و **`<Trans>`** لتضمين العناصر/المكونات؛ ICU متاح عبر الإضافة. - **Intlayer**: يمكن لملفات المحتوى أن تتضمن **عقد غنية** (JSX/Markdown/مكونات) و**بيانات وصفية**. التنسيق يستخدم Intl في الخلفية؛ أنماط الجمع مريحة الاستخدام. **لماذا هذا مهم:** نصوص واجهة المستخدم المعقدة (روابط، أجزاء غامقة، مكونات مضمنة) تصبح أسهل عندما تتبنى المكتبة عقد React بشكل نظيف. --- ### 5) الأداء وسلوك التحميل - **react-intl / react-i18next**: عادةً ما تدير **تقسيم الكتالوج** و**التحميل الكسول** يدويًا (المساحات الاسمية/الاستيرادات الديناميكية). فعال لكنه يتطلب انضباطًا. - **Intlayer**: يقوم بـ **إزالة الشجرية** للقواميس غير المستخدمة ويدعم **التحميل الكسول لكل قاموس/لكل لغة** بشكل مدمج. **لماذا هذا مهم:** الحزم الأصغر وسلاسل النصوص غير المستخدمة الأقل تحسن من أداء بدء التشغيل والتنقل. --- ### 6) تجربة المطور، الأدوات والصيانة - **react-intl / react-i18next**: نظام بيئي واسع للمجتمع؛ في سير العمل التحريري عادةً ما تعتمد على منصات الترجمة الخارجية. - **Intlayer**: يقدم **محررًا بصريًا مجانيًا** و**نظام إدارة محتوى اختياري** (احتفظ بالمحتوى في Git أو خارجه). كما يوفر **امتداد VSCode** لتأليف المحتوى و**ترجمة بمساعدة الذكاء الاصطناعي** باستخدام مفاتيح المزود الخاصة بك. **لماذا هذا مهم:** الأدوات المدمجة تقصر الحلقة بين المطورين ومؤلفي المحتوى - كود لاصق أقل، واعتماديات بائعين أقل. --- ## متى تختار أيًّا منها؟ - **اختر react-intl** إذا كنت تريد تنسيق رسائل **ICU-first** مع واجهة برمجة تطبيقات مباشرة ومتوافقة مع المعايير وكان فريقك مرتاحًا للحفاظ على الكتالوجات وفحوصات الأمان يدويًا. - **اختر react-i18next** إذا كنت تحتاج إلى **اتساع نظام i18next البيئي** (الكاشفات، الخلفيات، إضافة ICU، التكاملات) وتقبل المزيد من التهيئة للحصول على مرونة. - **اختر Intlayer** إذا كنت تقدر **المحتوى المحدد بالمكون**، و**TypeScript الصارم**، و**ضمانات وقت البناء**، و**tree-shaking**، وأدوات التحرير **المتضمنة بالكامل** - خاصة لتطبيقات React **الكبيرة والمودولارية**. --- ## ملاحظات عملية للهجرة (من react-intl / react-i18next إلى Intlayer) - **هاجر بشكل تدريجي**: ابدأ بميزة واحدة أو مسار واحد؛ احتفظ بكتالوجات النظام القديم بالتوازي أثناء الانتقال. - **اعتمد على قواميس لكل مكون**: ضع المحتوى بجانب المكونات لتقليل الترابط. - **فعّل الفحوصات الصارمة**: دع أخطاء وقت البناء تكشف عن المفاتيح/اللغات المفقودة مبكرًا في CI. - **قِس حجم الحزم**: توقع تقليصات مع تقليم السلاسل غير المستخدمة. --- ## الخلاصة جميع المكتبات الثلاث تقوم بتوطين React بفعالية. الفارق هو مقدار **البنية التحتية** التي يجب عليك بناؤها للوصول إلى إعداد **آمن وقابل للتوسع**: - مع **Intlayer**، يكون **المحتوى المعياري**، و**الكتابة الصارمة في TypeScript**، و**السلامة أثناء وقت البناء**، و**حزم مشذبة بالشجرة**، و**أدوات التحرير** هي الافتراضات - وليست مهامًا مرهقة. - إذا كانت فرقك تقدر **قابلية الصيانة والسرعة** في تطبيقات React متعددة اللغات وموجهة بالمكونات، فإن Intlayer تقدم **أكمل** سير عمل للمطورين والمحتوى اليوم.