שאלו את שאלתכם וקבלו סיכום של המסמך על ידי הפניה לדף הזה ולספק ה-AI שתבחרו
התוכן של הדף הזה תורגם באמצעות AI.
צפייה בגרסה האחרונה של התוכן המקורי באנגליתאם יש לכם רעיון לשיפור התיעוד הזה, אל תהססו לתרום על ידי הגשת Pull Request ב-GitHub.
קישור GitHub לתיעודהעתקת ה-Markdown של המסמך ללוח
next-i18next מול next-intl מול Intlayer

בואו נבחן את קווי הדמיון וההבדלים בין שלוש אפשרויות i18n עבור Next.js: next-i18next, next-intl ו-Intlayer.
זהו אינו מדריך שלב אחר שלב, אלא השוואה מקיפה שנועדה לסייע לכם לבחור את הכלי המתאים ביותר.
אנו מתמקדים ב-Next.js 13+ App Router (עם React Server Components) ומעריכים את היכולות הבאות:
תקציר (tl;dr): שלושת הפתרונות מאפשרים לתרגם יישום Next.js. אם אתם מחפשים תוכן מבודד ברמת הקומפוננטה, טיפוסי TypeScript קפדניים, בדיקות מפתחות חסרים בזמן build, מילונים שעוברים tree-shaking, ותמיכה מובילה ב-App Router ועזרי SEO, הרי ש-Intlayer היא הבחירה השלמה והמודרנית ביותר.
בלבול נפוץ בקרב מפתחים הוא המחשבה ש-next-intlהיא גרסת ה-Next.js שלreact-intl. זה אינו המצב:next-intlמתוחזקת על ידי Amann, בעוד ש-react-intlמתוחזקת על ידי FormatJS.
בקצרה
- next-intl - עיצוב הודעות קל משקל וישיר עם תמיכה טובה ב-Next.js. נפוץ להשתמש בקטלוגים מרכזיים; חוויית המפתח פשוטה, אך בטיחות ותחזוקה בפרויקטים גדולים נשארות ברובן באחריותכם.
- next-i18next - ספריית i18next בלבוש מותאם ל-Next.js. אקוסיסטם בוגר ותכונות רבות באמצעות תוספים (כגון ICU), אך ההגדרה עלולה להיות מסורבלת והקטלוגים נוטים להתנפח ככל שהפרויקט צומח.
- Intlayer - מודל תוכן ממוקד קומפוננטה עבור Next.js, אכיפת טיפוסים קפדנית ב-TypeScript, בדיקות בזמן build, tree-shaking מובנה, middleware מובנה ועזרי SEO, עורך ויזואלי ו-CMS אופציונליים, ותרגומים בסיוע AI.
פתיחת הטבלה בחלון כדי לראות את כל תוכן הנתונים בבירור
התגים מתעדכנים אוטומטית. הנתונים עשויים להשתנות לאורך זמן.
השוואת תכונות ראש בראש (עבור Next.js)
פתיחת הטבלה בחלון כדי לראות את כל תוכן הנתונים בבירור
| תכונה | next-intlayer (Intlayer) | next-intl | next-i18next |
|---|---|---|---|
| תרגומים צמודים לקומפוננטות | ✅ כן, תוכן ממוקם לצד כל קומפוננטה | ❌ לא | ❌ לא |
| אינטגרציה עם TypeScript | ✅ מתקדמת, טיפוסים קפדניים אוטומטיים | ✅ טובה | ⚠️ בסיסית |
| זיהוי תרגומים חסרים | ✅ שגיאת TypeScript + שגיאה/אזהרה בזמן build | ⚠️ ברירת מחדל בזמן ריצה | ⚠️ ברירת מחדל בזמן ריצה |
| תוכן עשיר (JSX/Markdown/קומפוננטות) | ✅ תמיכה ישירה ומלאה | ❌ לא תוכננה לצמתים עשירים | ⚠️ מוגבלת |
| תרגום מבוסס AI | ✅ כן, תמיכה במספר ספקים עם מפתחות ה-API שלכם. מתחשב בהקשר האפליקציה ובטווח התוכן | ❌ לא | ❌ לא |
| עורך ויזואלי | ✅ כן, עורך מקומי + CMS אופציונלי; מאפשר החצנת תוכן הקוד; ניתן להטמעה | ❌ אין / זמין דרך פלטפורמות לוקליזציה חיצוניות | ❌ אין / זמין דרך פלטפורמות לוקליזציה חיצוניות |
| ניתוב מתורגם (Localized Routing) | ✅ כן, תמיכה בנתיבים מתורגמים מהקופסה (Next.js ו-Vite) | ✅ מובנה, תמיכה במקטע [locale] ב-App Router | ✅ מובנה |
| יצירת נתיבים דינמית | ✅ כן | ✅ כן | ✅ כן |
| כללי רבים (Pluralization) | ✅ תבניות מבוססות ספירה (Enumeration) | ✅ טובה | ✅ טובה |
| עיצוב (תאריכים, מספרים, מטבעות) | ✅ מעבדי פורמט ממוטבים (Intl מתחת למכסה המנוע) | ✅ טובה (עזרי Intl) | ✅ טובה (עזרי Intl) |
| פורמט תוכן | ✅ .tsx, .ts, .js, .json, .md, .txt, (.yaml בפיתוח) | ✅ .json, .js, .ts | ⚠️ .json |
| תמיכה ב-ICU | ⚠️ בפיתוח | ✅ כן | ⚠️ באמצעות תוסף (i18next-icu) |
| עזרי SEO (hreflang, sitemap) | ✅ כלים מובנים: מפות אתר, robots.txt ומטא-דאטה | ✅ טובה | ✅ טובה |
| אקוסיסטם וקהילה | ⚠️ קטנה יותר אך בצמיחה מהירה ותגובתית | ✅ טובה | ✅ טובה |
| רינדור צד שרת ו-Server Components | ✅ מותאם בצורה חלקה ל-SSR ו-React Server Components | ⚠️ נתמך ברמת הדף אך דורש העברת פונקציות תרגום בעץ עבור קומפוננטות שרת צאצאיות | ⚠️ נתמך ברמת הדף אך דורש העברת פונקציות תרגום בעץ עבור קומפוננטות שרת צאצאיות |
| Tree-shaking (טעינת תוכן בשימוש בלבד) | ✅ כן, ברמת הקומפוננטה בזמן build דרך תוספי Babel/SWC | ⚠️ חלקי | ⚠️ חלקי |
| טעינה עצלה (Lazy loading) | ✅ כן, לכל שפה / לכל מילון | ✅ כן (לכל נתיב/שפה), דורש ניהול namespaces | ✅ כן (לכל נתיב/שפה), דורש ניהול namespaces |
| ניקוי תוכן שאינו בשימוש (Purge) | ✅ כן, לכל מילון בזמן build | ❌ לא, ניתן לניהול ידני דרך חלוקת namespaces | ❌ לא, ניתן לניהול ידני דרך חלוקת namespaces |
| ניהול פרויקטים גדולים | ✅ מעודד מודולריות, מתאים במיוחד ל-Design Systems | ✅ מודולרי עם הגדרה מתאימה | ✅ מודולרי עם הגדרה מתאימה |
| בדיקת תרגומים חסרים (CLI/CI) | ✅ CLI ייעודי: npx intlayer content test (ביקורת מותאמת CI) | ⚠️ אינו מובנה; התיעוד מציע את npx @lingual/i18n-check | ⚠️ אינו מובנה; מסתמך על כלי i18next או saveMissing בזמן ריצה |
מבוא
Next.js מעניקה תמיכה מובנית בניתוב בינלאומי (כגון מקטעי שפה בכתובת ה-URL). אך תכונה זו אינה מבצעת תרגומים בפני עצמה. אתם עדיין זקוקים לספרייה שתציג תוכן מתורגם למשתמשים שלכם.
ספריות i18n רבות קיימות כיום, אך בעולם ה-Next.js המודרני שלוש ספריות בולטות במיוחד: next-i18next, next-intl ו-Intlayer.
כדי להבין את מקורן של ספריות אלו, קראו על ההיסטוריה של בינאום ב-JavaScript.
ארכיטקטורה ויכולת הרחבה (Scalability)
- next-intl / next-i18next: מתבססות כברירת מחדל על קטלוגים מרוכזים לכל שפה (בתוספת namespaces ב-i18next). הדבר עובד מצוין בשלבים הראשונים, אך לעיתים קרובות הופך לקובץ ענק ומשותף המגביר תלויות וחיכוכים בין מפתחים סביב מפתחות תרגום.
- Intlayer: מעודדת מילונים לפי קומפוננטה (או לפי תכונה) הצמודים לקוד שהם משרתים. גישה זו מפחיתה עומס קוגניטיבי, מקלה על שכפול או ניוד של רכיבי ממשק משתמש, ומצמצמת התנגשויות בין צוותים. תוכן שאינו בשימוש קל יותר לזיהוי ולמחיקה.
מדוע זה חשוב: בבסיסי קוד גדולים או בהגדרות של Design Systems, תוכן מודולרי גדל בצורה בריאה בהרבה מקטלוגים מונוליטיים.
גדלי Bundle ותלויות
לאחר בניית האפליקציה, ה-bundle הוא ה-JavaScript שהדפדפן יוריד כדי לרנדר את הדף. גודל ה-bundle קריטי לביצועי האפליקציה.
ה-i18n benchmark מודד את ההשפעה המדויקת של כל ספרייה על אותו יישום Next.js בעל 10 דפים ו-10 שפות:
מדד
טעינת JSON דינמית
טעינה עצלה של תרגומים בזמן ריצה
JSON תחום (namespacing)
מרחבי שמות תרגום לכל דף
מהו המדד הזה?
הגודל הכולל לאחר דחיסת gzip של ה-bundle של ספריית הבינאום. הוא כולל רק את ה-provider ואת לוגיקת שליפת התוכן לאחר tree-shaking ומיזעור.
למה זה חשוב?
ספרייה קטנה יותר מקטינה את מטען ה-JavaScript ההתחלתי, מה שמוביל לזמני הורדה והרצה מהירים יותר בצד הלקוח.
הצגה כ
נתונים מרכזיים שנמדדו ב-Next.js App Router (בדחיסת gzip):
פתיחת הטבלה בחלון כדי לראות את כל תוכן הנתונים בבירור
| הגדרה | גודל ספרייה | ממוצע JS לדף | דליפת שפות אחרות | דליפת דפים אחרים | ממוצע לקומפוננטה |
|---|---|---|---|---|---|
| בסיס (ללא i18n) | - | 141.0 KB | 0.0% | 0.0% | 0.9 KB |
next-intl (סטטי) | 14.7 KB | 153.6 KB | 4.2% | 89.8% | 21.8 KB |
next-intl (דינמי) | 14.7 KB | 153.6 KB | 9.7% | 89.9% | 21.8 KB |
@intlayer/next-intl (תאימות) | 8.0 KB | 148.7 KB | 0.0% | 0.0% | 8.1 KB |
next-i18next (סטטי) | 19.7 KB | 218.5 KB | 0.0% | 89.8% | 78.5 KB |
next-i18next (דינמי) | 19.7 KB | 169.5 KB | 50.0% | 89.8% | 26.1 KB |
@intlayer/next-i18next (תאימות) | 9.4 KB | 150.7 KB | 0.0% | 0.0% | 9.7 KB |
next-intlayer (Intlayer מקורי) | 5.5 KB | 141.3 KB | 0.0% | 0.0% | 6.9 KB |
לניתוח המלא, ראו את דוח ביצועי Next.js ואת סקירת ה-benchmark המקיפה.
שני רכיבים חשובים בהקשר של bundle ביישום רב-לשוני:
- קוד האפליקציה
- התוכן הנטען על ידי הדפדפן
קוד האפליקציה
חשיבות קוד האפליקציה היא מינימלית במקרה זה. כל שלושת הפתרונות תומכים ב-tree-shaking, כלומר חלקים שלא נעשה בהם שימוש אינם נכללים ב-bundle.
הנה השוואה של גודל חבילת ה-JavaScript הנטענת על ידי הדפדפן עבור יישום רב-לשוני בשלושת הפתרונות.
אם אין לנו צורך במעבדי פורמט באפליקציה, רשימת הפונקציות המיוצאות לאחר tree-shaking תהיה:
- next-intlayer:
useIntlayer, useLocale, NextIntlClientProvider, (גודל ה-bundle הוא 180.6 kB -> 15.24 kB ב-gzip) - next-intl:
useTranslations, useLocale, NextIntlClientProvider, (גודל ה-bundle הוא 101.3 kB -> 31.4 kB ב-gzip) - next-i18next:
useTranslation, useI18n, I18nextProvider, (גודל ה-bundle הוא 80.7 kB -> 25.5 kB ב-gzip)
פונקציות אלו מהוות בעיקר מעטפת מסביב ל-React context/state, ולכן ההשפעה הכוללת של ספריית ה-i18n על גודל הקוד היא קטנה יחסית.
תוכן ותרגומים
חלק זה זוכה לעיתים קרובות להתעלמות מצד מפתחים, אך בואו נבחן מקרה של יישום המורכב מ-10 דפים ב-10 שפות. נניח שכל דף כולל 100% תוכן ייחודי כדי לפשט את החישוב (במציאות, חלק ניכר מהתוכן משותף, כגון כותרת עליונה, פוטר וכו').
משתמש המבקר בדף /fr/about אמור לטעון תוכן של דף בודד בשפה נתונה. התעלמות מאופטימיזציית תוכן משמעה טעינה של 8,200% ((1 + (((10 דפים - 1) × (10 שפות - 1)))) × 100) מתוכן האפליקציה ללא כל צורך. האם אתם מזהים את הבעיה? גם אם תוכן זה הוא טקסט בלבד, ואף על פי שסביר שאתם מעדיפים להתמקד באופטימיזציית תמונות, אתם שולחים תוכן מיותר ברחבי הרשת ומאלצים את מחשבי המשתמשים לעבד אותו לשווא.
שני נושאים קריטיים:
פיצול לפי נתיב:
אם אני נמצא בדף
/about, אינני רוצה לטעון את התוכן של דף הבית/homeפיצול לפי שפה:
אם אני נמצא בדף
/fr/about, אינני רוצה לטעון את התוכן של דף/en/about
הגרף להלן ממחיש כיצד כל סוג פיצול מתבטא באותו יישום של 10 דפים על 10 שפות, עם כ-30 KB טקסט לדף. ייבוא דינמי לפי שפה מסיר את ציר השפות, פיצול תוכן לפי נתיב או קומפוננטה מסיר את ציר הדפים, ורק השילוב ביניהם שומר על נפח נמוך וקבוע.

שלושת הפתרונות מודעים לבעיות אלו ומאפשרים לנהל אופטימיזציות אלו. ההבדל המרכזי הוא חוויית המפתח (DX).
next-intl ו-next-i18next משתמשות בגישה ריכוזית לניהול תרגומים, המאפשרת לפצל קובצי JSON לפי שפה ולפי תתי-קבצים. ב-next-i18next קבצים אלו נקראים 'namespaces'; ב-next-intl מגדירים אותם כהודעות (messages). ב-intlayer, אנו מכנים קבצים אלו 'מילונים' (dictionaries).
- ב-
next-intl, בדומה ל-next-i18next, התוכן נטען ברמת הדף או ה-layout, ואז מוזן לתוך context provider. המשמעות היא שהמפתח נדרש לנהל ידנית את קובצי ה-JSON הנטענים עבור כל דף.
בפועל, הדבר גורם למפתחים רבים לוותר על אופטימיזציה זו ולהעדיף לטעון את כל התוכן ב-provider של הדף למען הפשטות.
- ב-
intlayer, כל התוכן מוגדר לצד הקוד. תוסף קומפיילר (@intlayer/babel/@intlayer/swc) דואג לאופטימיזציית ה-bundle על ידי טעינת התוכן שנעשה בו שימוש בפועל באותו דף בלבד. המפתח אינו צריך לנהל ידנית את המילונים הנטענים. הדבר מוביל לאופטימיזציה גבוהה יותר, תחזוקתיות מעולה וחיסכון בזמן פיתוח.
ככל שהאפליקציה גדלה (במיוחד כשמספר מפתחים עובדים במקביל), שכיח לשכוח להסיר תוכן שאינו בשימוש מקובצי ה-JSON.
גישתה של Intlayer יעילה יותר: אם קומפוננטה מוסרת מהקוד, המילון שלה אינו נכלל עוד ב-bundle.
אופן הטיפול בברירות מחדל (fallbacks) חשוב לא פחות. נניח שהאפליקציה היא באנגלית כברירת מחדל, ומשתמש גולש לדף /fr/about. אם חסרים תרגומים בצרפתית, המערכת תיפול לאנגלית.
ב-next-intl וב-next-i18next, הספרייה נדרשת לטעון את ה-JSON של השפה הנוכחית, אך גם את זה של שפת ברירת המחדל. כך, גם בהנחה שכל התוכן תורגם במלואו, כל דף טוען 100% תוכן מיותר. לעומת זאת, Intlayer מעבדת את ברירת המחדל בזמן בניית המילונים. כך כל דף טוען אך ורק את התוכן הנחוץ.
הערה: כדי לבצע אופטימיזציה של ה-bundle באמצעותintlayer, יש להגדירimportMode: 'dynamic'בקובץintlayer.config.ts, ולוודא שהתוסף מותקן כראוי.
TypeScript ובטיחות טיפוסים
next-i18next
- טיפוסים בסיסיים ל-hooks. הקלדה קפדנית של מפתחות דורשת כלי עבודה והגדרות נוספות.
next-intl
- תמיכה טובה ב-TypeScript, אך מפתחות אינם מוקלדים באופן קפדני כברירת מחדל. יש לתחזק תבניות בטיחות באופן ידני.
intlayer
- יוצרת טיפוסים קפדניים אוטומטית ישירות מהתוכן שלכם. השלמה אוטומטית ב-IDE ושגיאות בזמן קומפילציה תופסות שגיאות הקלדה ומפתחות חסרים עוד לפני הפריסה.
מדוע זה חשוב: אכיפת טיפוסים חזקה מעבירה את גילוי השגיאות שמאלה (ל-CI ולבנייה) במקום ימינה (לזמן ריצה מול המשתמש).
טיפול בתרגומים חסרים
next-i18next
- מסתמכת על ברירות מחדל בזמן ריצה. תהליך הבנייה אינו נכשל.
next-intl
- מסתמכת על ברירות מחדל בזמן ריצה. תהליך הבנייה אינו נכשל.
intlayer
- זיהוי מוקדם בזמן build עם אזהרות ושגיאות קומפילציה עבור שפות או מפתחות חסרים.
מדוע זה חשוב: תפיסת חוסרים בזמן הבנייה מונעת מחרוזות 'undefined' או טקסט שגוי בייצור.
ניתוב, Middleware ואסטרטגיית כתובות (URL)
next-i18next
- מאפשרת ניתוב מתורגם, אך middleware אינו מובנה כחלק מהספרייה.
next-intl
- מאפשרת ניתוב מתורגם.
- מספקת middleware מובנה.
intlayer
- מאפשרת ניתוב מתורגם.
- מספקת middleware מובנה.
מדוע זה חשוב: מסייע לקידום אתרים (SEO), גילוי במנועי חיפוש וחוויית משתמש אינטואיטיבית.
התאמה ל-Server Components (RSC)
next-i18next
- תומכת ב-Server Components ברמת הדף וה-layout.
- אינה מספקת API סינכרוני לקומפוננטות שרת צאצאיות.
next-intl
- תומכת ב-Server Components ברמת הדף וה-layout.
- אינה מספקת API סינכרוני לקומפוננטות שרת צאצאיות.
intlayer
- תומכת ב-Server Components ברמת הדף וה-layout.
- מספקת API סינכרוני מלא עבור קומפוננטות שרת צאצאיות.
מדוע זה חשוב: תמיכה ב-Server Components היא תכונת ליבה של Next.js 13+ המשפרת ביצועים. העברת פרופס של שפה או פונקציות t מההורה לקומפוננטות שרת צאצאיות הופכת את הקומפוננטות לפחות מודולריות ולפחות ניתנות לשימוש חוזר.
אינטגרציה עם פלטפורמות לוקליזציה (TMS)
ארגונים גדולים מסתמכים לעיתים קרובות על מערכות ניהול תרגום (TMS) כגון Crowdin, Phrase, Lokalise, Localizely או Localazy.
מדוע חברות זקוקות לכך
- שיתוף פעולה ותפקידים: גורמים מרובים מעורבים: מפתחים, מנהלי מוצר, מתרגמים, מבקרים וצוותי שיווק.
- קנה מידה ויעילות: לוקליזציה רציפה וסקירה בהקשר הדף.
next-intl / next-i18next
- משתמשות לרוב בקטלוגי JSON מרוכזים, כך שייצוא וייבוא מול TMS הוא פשוט ומוכר.
- אקוסיסטם בוגר עם דוגמאות ואינטגרציות מוכחות לפלטפורמות הנ"ל.
Intlayer
- מעודדת מילונים מבוזרים לפי קומפוננטה ותומכת בתוכן מגוון: TypeScript/TSX/JS/JSON/MD.
- גישה זו משפרת את המודולריות בקוד, אך עשויה לדרוש התאמה מול כלי TMS המצפים לקובצי JSON שטוחים ומרוכזים.
- Intlayer מציעה חלופות מתקדמות: תרגום בסיוע AI (באמצעות מפתחות API אישיים), עורך ויזואלי / CMS, ותהליכי CLI/CI לזיהוי ומילוי חוסרים.
הערה: גםnext-intlו-i18nextתומכות בקטלוגי TypeScript. אם הצוות שלכם מאחסן הודעות בקובצי.tsאו מבזר אותן לפי תכונות, תיתקלו באתגרים דומים מול כלי TMS ישנים.
חוויית פיתוח (Developer Experience)
חלק זה מציג השוואה מעמיקה בין שלושת הפתרונות. במקום לבחון מקרים פשוטים מדי, נבחן תרחיש שימוש אמיתי הקרוב לפרויקט פרודקשן.
מבנה האפליקציה
מבנה היישום חיוני להבטחת תחזוקתיות הקוד לאורך זמן.
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
השוואה
- next-intl / next-i18next: קטלוגים מרוכזים (JSON; namespaces או messages). מבנה ברור המשתלב היטב עם פלטפורמות תרגום חיצוניות, אך עלול להוביל לעריכות מרובות קבצים ככל שהאפליקציה גדלה.
- Intlayer: מילוני
.content.{ts|js|json}צמודים ישירות לקומפוננטות שלהם. מקלים על שימוש חוזר בקומפוננטות והבנה מקומית של הקוד; מבוססים על כלי קומפילציה בזמן build.
הגדרה וטעינת תוכן
כיצד הספרייה מטפלת בטעינת תוכן:
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
השוואה
שלושת הפתרונות תומכים בטעינת תוכן לפי שפה וב-providers מתאימים.
- ב-next-intl/next-i18next, אתם בדרך כלל טוענים הודעות או namespaces נבחרים לכל נתיב וממקמים providers היכן שנדרש.
- ב-Intlayer, ניתוח בזמן build מזהה אוטומטית את השימוש ברכיבים, מה שמצמצם חיווט ידני ומאפשר שימוש ב-provider שורש יחיד.
שימוש בקומפוננטת לקוח (Client Component)
נבחן דוגמה לקומפוננטת לקוח המרנדרת מונה (counter).
תרגומים (קובץ JSON אחד לכל namespace תחת src/locales/...)
העתקת הקוד ללוח
העתקת הקוד ללוח
קומפוננטת לקוח (טוענת רק את ה-namespace הנדרש)
העתקת הקוד ללוח
תרגומים
העתקת הקוד ללוח
העתקת הקוד ללוח
קומפוננטת לקוח
העתקת הקוד ללוח
תוכן
העתקת הקוד ללוח
קומפוננטת לקוח
העתקת הקוד ללוח
השוואה
- עיצוב מספרים:
- next-i18next: אין
useNumber; יש להשתמש ב-Intl.NumberFormatישירות. - next-intl:
useFormatter().number(value). - Intlayer:
useNumber()מובנה.
- next-i18next: אין
- מפתחות:
- מבנה מקונן (
about.counter.label) המצריך הגדרת סקופ מתאים ב-hook.
- מבנה מקונן (
- מיקום קבצים:
- next-i18next מצפה ל-JSON ב-
public/locales/{lng}/{ns}.json. - next-intl גמישה באופן טעינת ההודעות.
- Intlayer שומרת תוכן במילוני TS/JS צמודים ומפענחת לפי מפתח.
- next-i18next מצפה ל-JSON ב-
שימוש בקומפוננטת שרת (Server Component)
נבחן מקרה של קומפוננטת ממשק שהיא Server Component, אך צריכה להיות מוזנת כצאצאית של קומפוננטת לקוח (Page -> ClientComponent -> ServerComponent). מכיוון שהיא מוכנסת כילד של קומפוננטת לקוח, היא אינה יכולה להיות פונקציה אסינכרונית (async).
העתקת הקוד ללוח
העתקת הקוד ללוח
מכיוון שקומפוננטת שרת זו אינה יכולה להיות async, יש להעביר את התרגומים ואת פונקציית העיצוב כפרופס.
העתקת הקוד ללוח
Intlayer חושפת hooks בטוחים לשרת דרךnext-intlayer/server. useIntlayerו-useNumberפועלים בתחביר דמוי-hooks סינכרוני, אך נשענים מתחת למכסה המנוע על context השרת (IntlayerServerProvider).
מטא-דאטה / Sitemap / Robots
תרגום תוכן הוא נהדר, אך המטרה המרכזית בבינאום היא להפוך את האתר שלכם לנראה ולנגיש יותר לעולם. i18n הוא מנוף אדיר לקידום האתר (SEO).
להלן רשימת נהלים מומלצים ב-SEO רב-לשוני:
- הגדרת תגי מטא
hreflangבתוך תגית ה-<head> - רישום תרגומי כל הדפים בתוך
sitemap.xmlבאמצעות סכמת ה-XML שלhttp://www.w3.org/1999/xhtml - איסור סריקה (disallow) של נתיבים בעלי קידומת ב-
robots.txtעבור דפים מוגנים (כגון/dashboard, וכן/fr/dashboard,/es/dashboard) - שימוש בקומפוננטת קישור מותאמת לניתוב לדף המתורגם ביותר
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
העתקת הקוד ללוח
Intlayer מספקת את הפונקציה getMultilingualUrls ליצירה אוטומטית של כתובות רב-לשוניות עבור מפת האתר שלכם.
Middleware לניתוב שפות
העתקת הקוד ללוח
העתקת הקוד ללוח
Intlayer מספקת טיפול מובנה ב-middleware דרך הגדרות חבילת next-intlayer.
העתקת הקוד ללוח
הגדרת ה-middleware מתבצעת בצורה מרוכזת בקובץ intlayer.config.ts.
רשימת נהלים מומלצים
- הגדירו
langו-dirב-<html>השורשי ב-src/app/[locale]/layout.tsx. - פצלו תרגומים ל-namespaces (כגון
common.json,about.json) תחתsrc/locales/<locale>/. - טענו רק את ה-namespaces הנדרשים בקומפוננטות לקוח באמצעות
useTranslation('<ns>')והגדרת סקופ מתאים ב-I18nProvider. - שמרו על דפים סטטיים במידת האפשר: הגדירו
export const dynamic = 'force-static'ויישמוgenerateStaticParams. - בקומפוננטות שרת מקוננות תחת קומפוננטות לקוח, העבירו מחרוזות מוכנות או את פונקציית
tוהשפה כפרופס. - עבור SEO, הגדירו
alternates.languagesבמטא-דאטה, רשמו כתובות מתורגמות ב-sitemap.ts, והחריגו נתיבים כפולים ב-robots.txt.
- הגדרת
langו-dirב-HTML: חשבו את הכיוון דרךgetLocaleDirection(locale)והגדירו<html lang={locale} dir={dir}>. - פיצול הודעות לפי namespace: ארגנו קובצי JSON לפי שפה ו-namespace (כגון
common.json,about.json). - צמצום המשקל לצד הלקוח: שלחו רק namespaces נדרשים ל-
NextIntlClientProvider(למשלpick(messages, ['common', 'about'])). - העדפת דפים סטטיים: ייצאו
export const dynamic = 'force-static'וצרו פרמטרים סטטיים לכל השפות. - Server Components סינכרוניים: שמרו על קומפוננטות שרת סינכרוניות על ידי העברת מחרוזות מחושבות מראש.
- תוכן מודולרי: מקמו מילוני תוכן בצמוד לקומפוננטות באמצעות קובצי
.content.{ts|js|json}. - בטיחות טיפוסים: נצלו את האינטגרציה עם TypeScript לאימות תוכן בזמן קומפילציה.
- אופטימיזציה בזמן build: השתמשו בכלי הבנייה של Intlayer לביצוע אוטומטי של tree-shaking ואופטימיזציית bundle.
- כלי עבודה מובנים: נצלו את תמיכת הניתוב המובנית, עזרי ה-SEO, והעורך הוויזואלי.
והמנצחת היא…
אין לכך תשובה פשוטה אחת, שכן לכל אפשרות יש יתרונות וחסרונות:
next-i18next
- בוגרת, עשירה בתכונות ובתוספי קהילה, אך בעלת עלות הגדרה גבוהה יותר. מתאימה למי שזקוק לאקוסיסטם התוספים של i18next (כגון כללי ICU מתקדמים דרך תוספים) וצוותו כבר שולט בה, ומקבל על עצמו יותר הגדרות ידניות תמורת גמישות זו.
next-intl
- פשוטה, קלת משקל, ומחייבת פחות החלטות מורכבות. מתאימה למי שמחפש פתרון מינימליסטי, שמרגיש בנוח עם קטלוגים מרכזיים, והאפליקציה שלו היא בגודל קטן עד בינוני.
Intlayer
- נבנתה במיוחד עבור Next.js מודרנית, עם תוכן מודולרי, בטיחות טיפוסים מלאה ופחות קוד מסורבל (boilerplate). מתאימה למי שמעריך תוכן מבודד לקומפוננטה, TypeScript קפדני, בדיקות בזמן build, tree-shaking אוטומטי, וארגז כלים מלא לניתוב, SEO ועריכה חזותית - במיוחד עבור Next.js App Router, ספריות רכיבים ובסיסי קוד מודולריים גדולים.
אם אתם מעדיפים הגדרה מינימלית ומקבלים על עצמכם חיווט ידני מסוים, next-intl היא בחירה טובה. אם אתם זקוקים לכל התכונות המסורתיות ולא חוששים ממורכבות, next-i18next תספק את הסחורה. אך אם אתם מחפשים פתרון מודרני, מדרגי ומודולרי עם כלי עבודה מתקדמים מהקופסה, Intlayer מספקת בדיוק את המענה הזה.
חלופה לצוותים בארגונים גדולים: אם אתם זקוקים לפתרון ותיק שמשתלב חלקית עם פלטפורמות לוקליזציה מבוססות כגון Crowdin או Phrase, שקלו את next-intl או next-i18next בשל האקוסיסטם הבוגר שלהן.
מפת דרכים עתידית: Intlayer מפתחת גם תוספי תאימות הפועלים על גבי פתרונות i18next ו-next-intl. הדבר מאפשר ליהנות מיתרונות האוטומציה, התחביר וניהול התוכן של Intlayer, תוך שמירה על היציבות של הספריות הקיימות בקוד שלכם.
כוכבי GitHub
כוכבי GitHub הם אינדיקטור מובהק לפופולריות של פרויקט, לאמון הקהילה ולרלוונטיות ארוכת טווח. למרות שאינם מדד ישיר לאיכות טכנית, הם משקפים כמה מפתחים מוצאים את הפרויקט שימושי, עוקבים אחר התקדמותו ונוטים לאמץ אותו.
פעילות Commits
כוכבים מעידים על פופולריות. Commits מראים כמה עבודה מושקעת בפרויקט בפועל. במועד כתיבת שורות אלו, Intlayer מונה כ-7,500 commits, יותר ממרבית הספריות המושוות כאן, ובערך פי 5 יותר מ-next-intl או next-i18next.
- i18next/next-i18next
- amannn/next-intl
- aymericzip/intlayer
Commits בענף ברירת המחדל, מקור: GitHub API.
Intlayer היא monorepo, כך שהספירה כוללת את כל חבילות המסגרות, ה-CLI והתיעוד. קראו commits כסימן לפעילות מתמשכת, ולא כמדד ישיר לאיכות.
הורדות ב-npm
- next-i18next
- next-intl
- next-intlayer
מקור: API ההורדות של מאגר npm.
הורדות מתגמלות את הפתרונות הוותיקים ביותר, ולא בהכרח את הטובים ביותר. ספרייה ששוחררה לפני שנים עדיין מותקנת על ידי כל פרויקט שבחר בה בעבר, בכל הרצת CI ועל ידי כל חבילה שתלויה בה. הספירה משקפת אינרציה יותר מאשר בחירה עדכנית.
עוזרי AI מגבירים את האפקט הזה. next-intl, i18next ו-vue-i18n מופיעות בכל מקום בקוד שעליו הם אומנו, ולכן הם ממליצים עליהן כברירת מחדל, ללא השוואה מעמיקה לחלופות. כל המלצה כזו מוסיפה הורדות, מה שמזין את ההמלצה הבאה. מומלץ להשוות על פי נתוני מבחני הביצועים ולא על פי כמות ההורדות.
סיכום
שלושת הפתרונות מצליחים במשימת הבינאום הבסיסית. ההבדל המהותי טמון ב-כמה עבודה ידנית עליכם להשקיע כדי להשיג מערך יציב ומדרגי ב-Next.js מודרנית:
- עם Intlayer, תוכן מודולרי, TypeScript קפדני, בטיחות בזמן build, bundles שעוברים tree-shaking, וכלי עבודה מובנים ל-App Router ול-SEO הם ברירת המחדל, ולא מטלה נוספת.
- אם הצוות שלכם מעריך תחזוקתיות ומהירות פיתוח ביישום מונחה קומפוננטות רב-לשוני, Intlayer מציעה כיום את החוויה השלמה ביותר.
קריאה נוספת ומבחני ביצועים
עיינו במסמך 'למה Intlayer?' לפרטים נוספים.
תגובות
עדיין אין תגובות. היו הראשונים לשתף את מחשבותיכם.
