כיצד לבחור את ספריית ה-i18n הנכונה ל-Svelte

Svelte אינה כוללת שום דבר מובנה עבור i18n. אין $t, אין פרימיטיב לניהול locale, ואין פורמט הודעות רשמי. כל אפשרות היא בחירה של צד שלישי, והאקוסיסטם של Svelte הוא המקום שבו i18n בזמן בנייה הרחיק לכת יותר מכל, כך שהמועמדים שונים זה מזה באופן מהותי יותר מאשר ב-React או ב-Vue.

מדריך זה מונה תחילה את השאלות שיש לענות עליהן, ולאחר מכן מתאים את התשובות ל-svelte-i18n, Paraglide, typesafe-i18n, wuchale ו-Intlayer, עבור Vite + Svelte ועבור SvelteKit.

תוכן העניינים

שש שאלות שיש לענות עליהן לפני שמשווים בין ספריות

1. Vite SPA או SvelteKit? ב-SPA, שימוש ב-store ברמת המודול (module-level store) הוא תקין: לשונית אחת, משתמש אחד, שפה אחת. ב-SvelteKit אותו מופע יחיד (singleton) משותף לרוחב בקשות מקבילות בשרת, ובקשה ב' תתרנדר בשפה של בקשה א'. הספרייה חייבת לספק לכם מבנה מבודד לכל בקשה (context, locals) או שתצטרכו להקים זאת בעצמכם.
2. מי כותב את התרגומים? מפתחים, מערכת TMS, סוכנות המספקת מחרוזות ICU, או צינור אוטומטי מבוסס AI. הספרייה svelte-i18n מבוססת על ICU. הספריות Paraglide ו-typesafe-i18n משתמשות בתחביר משלהן. התאימו את הכלי לספק התוכן שלכם.
3. כמה שפות ועמודים יש באפליקציה? שתי שפות וחמישה עמודים יכולים לטעון הכל מראש. עשר שפות וארבעים נתיבים לא יכולים, וההבדל בין קטלוגים בזמן ריצה לבין הודעות מקומפלות הופך לגורם העלות העיקרי.
4. האם אתם זקוקים לטיפוסים על מפתחות (Types on keys)? קריאה ל-$_("cart.totl") היא כשל בזמן ריצה ב-svelte-i18n. ספריות זמן בנייה הופכות זאת לשגיאת טיפוסים (type error) כחלק מהמבנה שלהן.
5. Svelte 4 stores או Svelte 5 runes? מנגנון ה-Runes משנה את התחביר של ניהול המצב, לא את בעיית השיתוף בשרת. אולם $state בקובץ .ts מתקמפל למשתנה רגיל, כך שסביבת זמן הריצה של הספרייה חייבת לתמוך ב-runes אם אתם משתמשים ב-Svelte 5.
6. האם אתם יכולים לחיות עם קבצים שנוצרים אוטומטית במאגר הקוד? גם Paraglide וגם typesafe-i18n מייצרות קובצי JavaScript או TypeScript ישירות בתוך עץ המקור שלכם. חלק מהצוותים מקבלים זאת בהבנה, ואחרים נתקלים בקונפליקטים במיזוגים בכל ענף מקביל.

רשמו לעצמכם את התשובות. כל הניתוח שלהלן מתייחס אליהן ישירות.

תמונת המצב הכוללת

ה-i18n ב-Svelte הגיע מאוחר יותר מאשר ב-React או ב-Vue, ודילג ישירות אל גלי הזמן-בנייה והמהדרים.

המאמר על ההיסטוריה של בינאום ב-JavaScript מכסה כל גל בהרחבה.

ההחלטה החשובה ביותר: היכן התוכן שמור ומתי הוא נטען

שתי בחירות מבניות מסבירות את מרבית ההבדלים בגודל ה-bundle בין ההגדרות השונות:

• תוכן מרוכז או מתוחם (Scoped): קובץ locales/en.json יחיד לכל האפליקציה, או הצהרה אחת לכל רכיב.
• ייבוא סטטי או דינמי: הכל נטען עם הפעלת האפליקציה, או שהשפה הפעילה (ובאופן אידיאלי גם הנתיב הפעיל) נמשכים לפי דרישה.

התרשים מעריך את גודל המידע של אפליקציה תיאורטית בעלת 1 עד 10 עמודים, המתורגמת ל-1 עד 10 שפות, עם כ-30 KB של טקסט לכל עמוד.

הספרייה svelte-i18n ממוקמת בפינה השמאלית העליונה כברירת מחדל: שימוש ב-register("fr", () => import("./fr.json")) מעניק טעינה דינמית לכל שפה, אך קטלוג השפה הוא אובייקט אחד וטעינתו טוענת את הטקסטים של כל העמודים. Paraglide היא המקרה המעניין: מכיוון שכל הודעה מיוצאת בנפרד, מנגנון ה-tree-shaking מסיר את ציר העמודים ללא מאמץ נוסף, ומבחן הביצועים של Svelte benchmark מאשר שזה פועל כמובטח ב-Vite + Svelte (בניגוד למבחני React ו-Next.js). הספרייה Intlayer מגיעה לאותה תוצאה באמצעות הצהרות צמודות-רכיב.

אם תשובתכם לשאלה 3 הייתה "עמודים רבים", העניקו לחלק זה משקל רב יותר מכל העדפת תחביר API. המאמר על i18n ברמת הרכיב לעומת מרוכז עוסק בהשלכות התחזוקה של פשרה זו.

הספריות המועמדות

גדלי הספריות מבוססים על תוצאות ה-Svelte benchmark: store בתוספת accessor בתוך רכיב ריק, לאחר bundling, tree-shaking ו-minification, באפליקציה של 10 עמודים ו-10 שפות. התוכן נמדד בנפרד.

המספרים מייצגים תמונת מצב בגרסאות שנבדקו במבחן ההשוואה. הריצו את הבדיקה על האפליקציה שלכם לפני קבלת החלטה על סמך גודל בלבד. בטיחות טיפוסים: ציון 5/5 מעיד על כך שמפתחות, פרמטרים וכל שפה נבדקים ללא צורך בהגדרה ידנית, כולל מעצבי כתובות URL וכלי עזר.

גודל הספרייה האפסי כמעט של Paraglide נובע מעצם המבנה שלה: קוד זמן הריצה נוצר ישירות בתוך מאגר הקוד שלכם. Intlayer זקוקה לתוסף vite-intlayer, ולכן אינה יכולה לפעול ללא שלב בנייה.

פעילות Commits

כמות ה-commits משקפת כמה מאמץ פיתוח מושקע בכל פרויקט. מונו-ריפו סופר כל חבילה שהוא משחרר, לכן יש לקרוא את המספר כאינדיקציה לפעילות שוטפת ולא בהכרח כמדד איכות.

הורדות ב-npm

נתוני הורדות מתגמלים פתרונות ותיקים ולא בהכרח את הטובים ביותר. ספרייה ששוחררה לפני שנים עדיין מותקנת על ידי כל פרויקט שבחר בה בעבר, בכל הרצת CI ועל ידי כל חבילה שתלויה בה. הכמות משקפת אינרציה ולא בהכרח בחירה עדכנית.

עוזרי AI מעצימים את האפקט. ספריות כמו next-intl, i18next ו-vue-i18n נפוצות בכל הקוד שעליו אומנו המודלים, ולכן הם מציעים אותן כברירת מחדל מבלי להשוות חלופות. כל הצעה מובילה להורדות נוספות, שמזינות את ההמלצה הבאה. מומלץ להשוות על פי תוצאות ה-benchmark ולא על פי מדדי הורדות.

התאימו את התשובות שלכם לספרייה

היכן כל ספרייה מתקשה

• svelte-i18n: הכבדה ביותר בקבוצה, ללא טיפוסים על מפתחות, ללא פיצול לפי נתיב, ו-store ברמת המודול שדולף בין בקשות שונות ב-SvelteKit אלא אם תחברו context בעצמכם.
• typesafe-i18n: דורשת תהליך watcher פעיל, מייצרת קבצים בתוך המאגר, והמאגר לא רשם פעילות משמעותית לאחרונה.
• Paraglide: קבצים הנוצרים ישירות בתוך המאגר שיש לייצר מחדש לפני כל push, קונפליקטים במיזוגים בענפים מקבילים, והשפה נקראת מעוגייה או אחסון בכל קריאת הודעה במקום מתוך store, מה שגורר עבודה מיותרת בהחלפת שפה.
• wuchale: רעיון חילוץ מעניין, אך עדיין בשלבים מוקדמים. במבחן הביצועים של React התגלו בעיות ריאקטיביות שחייבו כפיית רינדור של ה-provider, והתיעוד מצומצם למדי.
• Intlayer: מחייבת תוסף בנייה, אקוסיסטם קטן יותר, תמיכת ICU חלקית, ותוכן המפוזר בבסיס הקוד מעצם התכנון, כך שייצוא JSON בודד למתרגם דורש שימוש בכלי עזר.

כיצד כל אפשרות נראית בקוד

אותו רכיב בדיוק, סיכום עגלת קניות עם כותרת וצורת ריבוי, כתוב בכל אחת מהספריות. החלק המעניין אינו התבנית עצמה, אלא המקום שבו התוכן נשמר, כיצד השפה מנוהלת, ומה בודק הטיפוסים יודע עליה.

{
  "cart": {
    "title": "Your cart",
    "items": "{count, plural, one {# item} other {# items}}"
  }
}

{
  "cart": {
    "title": "Votre panier",
    "items": "{count, plural, one {# article} other {# articles}}"
  }
}

{
  "cart": {
    "title": "Tu carrito",
    "items": "{count, plural, one {# artículo} other {# artículos}}"
  }
}

<script lang="ts">
  import { _ } from "svelte-i18n";

  let { count }: { count: number } = $props();
</script>

<section>
  <h2>{$_("cart.title")}</h2>
  <p>{$_("cart.items", { values: { count } })}</p>
</section>

{
  "cart_title": "Your cart",
  "cart_items": "{count} items"
}

{
  "cart_title": "Votre panier",
  "cart_items": "{count} articles"
}

{
  "cart_title": "Tu carrito",
  "cart_items": "{count} artículos"
}

<script lang="ts">
  import { m } from "$lib/paraglide/messages.js";

  let { count }: { count: number } = $props();
</script>

<section>
  <h2>{m.cart_title()}</h2>
  <p>{m.cart_items({ count })}</p>
</section>

import type { BaseTranslation } from "../i18n-types";

const en = {
  cart: {
    title: "Your cart",
    items: "{count} item{{s}}",
  },
} satisfies BaseTranslation;

export default en;

import type { Translation } from "../i18n-types";

const fr = {
  cart: {
    title: "Votre panier",
    items: "{count} article{{s}}",
  },
} satisfies Translation;

export default fr;

import type { Translation } from "../i18n-types";

const es = {
  cart: {
    title: "Tu carrito",
    items: "{count} artículo{{s}}",
  },
} satisfies Translation;

export default es;

<script lang="ts">
  import LL from "$i18n/i18n-svelte";

  let { count }: { count: number } = $props();
</script>

<section>
  <h2>{$LL.cart.title()}</h2>
  <p>{$LL.cart.items({ count })}</p>
</section>

import { plural, t, type Dictionary } from "intlayer";

const cartSummaryContent = {
  key: "cart-summary",
  content: {
    title: t({
      en: "Your cart",
      fr: "Votre panier",
      es: "Tu carrito",
    }),
    items: t({
      en: plural({ one: "{{count}} item", other: "{{count}} items" }),
      fr: plural({ one: "{{count}} article", other: "{{count}} articles" }),
      es: plural({ one: "{{count}} artículo", other: "{{count}} artículos" }),
    }),
  },
} satisfies Dictionary;

export default cartSummaryContent;

<script lang="ts">
  import { useIntlayer } from "svelte-intlayer";

  let { count }: { count: number } = $props();
  const content = useIntlayer("cart-summary");
</script>

<section>
  <h2>{$content.title}</h2>
  <p>{$content.items(count)}</p>
</section>

כבר משתמשים ב-svelte-i18n? מתאם התאימות של @intlayer/svelte-i18n מספק כינוי (alias) לחבילה ברמת ה-bundler, כך ש-$_, $date, $number והמפתחות השטוחים שלכם ממשיכים לפעול בזמן ש-Intlayer מגישה את התוכן.

נקודות למחשבה לפני שמתחייבים

טבלת תכונות מציגה מה הספרייה יודעת לעשות כיום. הנקודות הבאות ממחישות כיצד תיראה שגרת החיים איתה.

בדקו את פעילות המאגר (Repository Activity).

כמות commits, זמן מענה ל-issues, והאם גרסת ה-minor האחרונה שוחררה השנה. תכנון מעולה ללא מתחזק פעיל הוא הגירה שמחכה לקרות.

אל תבחרו לפי כמות ההורדות ב-npm.

הספרייה המותקנת ביותר היא זו ששוחררה ראשונה, לא זו שהכי מתאימה לבסיס קוד של Svelte ב-2026. הורדות מודדות היסטוריה, לא התאמה.

שאלו מי מממן את המתחזק, ומה הוא מוכר.

הספרייה svelte-i18n נתמכת על ידי Crowdin, בדומה ל-next-intl ו-vue-i18n. הספרייה i18next נתמכת על ידי Locize. הספריות Tolgee, Paraglide (inlang) ו-Intlayer מפעילות כל אחת פלטפורמה משלה. לספק שרווחיו מבוססים על אחסון תרגומים בענן יש אינטרס נמוך מאוד לספק תרגום חינמי ישירות בתוך כלי הפיתוח שלכם. Intlayer היא היחידה בקבוצה שמספקת תרגום AI דרך ה-CLI עם מפתח API אישי שלכם, ומערכת CMS שניתן לארח עצמאית.

האם הספרייה מוכנה לסוכני AI (AI Agents)?

סוכנים מתקשים לעיתים קרובות עם i18n: הם שוכחים שפות, ממציאים מפתחות ומערבבים תחבירי הודעות. האם הספרייה מספקת Agent Skills או שרת MCP כך שהסוכן יוכל לרשום, למלא ולבדוק תוכן? והאם טעינת התוכן ממוטבת כברירת מחדל, או שמישהו יצטרך לבדוק namespaces וטעינות מושהות מדי רבעון?

בטיחות טיפוסים (Type safety) מהקופסה.

לא "יכולה לתמוך בטיפוסים עם הגדרות נוספות", אלא "מפתח שגוי מכשיל את tsc בהתקנה חדשה". בדקו מה קורה עם מפתח שאינו קיים, ועם שפה שחסר בה תרגום אחד.

זיהוי תוכן שאינו בשימוש.

קטלוגים נוטים רק לגדול. תהליך הבנייה של Intlayer מנקה שדות שאינם בשימוש ומתעד אותם (build.purge). הספרייה Paraglide משיגה זאת באופן מבני, מכיוון שפונקציית הודעה שאינה נקראת מוסרת ב-tree-shaking. כל שאר הספריות משאירות את הניקוי לאחריותכם.

חוויית פיתוח (DX).

זמן הגדרה עד למחרוזת המתורגמת הראשונה, תמיכת LSP או תוסף VS Code המציג את התרגום בריחוף (hover) ומקפיץ להצהרה, CLI למילוי, בדיקה ודחיפת תוכן, מהדר או מחלץ המוציא מחרוזות מקודדות מתוך הרכיבים כדי שלא תנהלו כל מחרוזת מפתח-אחר-מפתח, ואפשרות לאנשי תוכן שאינם מפתחים לערוך תוכן (עורך ויזואלי או CMS) ללא צורך ב-pull request.

שאלות נפוצות

קריאה נוספת

מדריכים מקבילים עבור