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

"Vue i18n" הוא גם מונח כללי וגם שמה של הספרייה שכמעט כולם מתקינים. זהו מצב נוח אך גם מטעה: vue-i18n היא ברירת מחדל טובה, אך היא אינה האפשרות היחידה, והשאלות שאמורות להניע את הבחירה (SSR או לא, כמה עמודים קיימים, מי כותב את התרגומים) נשאלות לעיתים נדירות לפני שמריצים npm install.

מדריך זה שואל את השאלות הללו תחילה, ולאחר מכן מתאים את התשובות לספריות המתאימות ביותר, עבור Vite + Vue ועבור Nuxt.

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

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

1. Vite SPA או Nuxt? ב-SPA, עלות הקטלוג היא בעיה של גודל חבילת ה-JS. ב-Nuxt זו גם בעיה של משקל ה-HTML, מכיוון שההודעות עוברות סריאליזציה לתוך ה-state של ה-SSR ועוברות הידרציה. מסיבה זו, רוב הדיווחים בנוסח "vue-i18n איטית" מגיעים מאפליקציות Nuxt.
2. מי כותב את התרגומים? מפתחים, מערכת TMS, סוכנות המספקת מחרוזות בפורמט ICU, או צינור אוטומטי של AI. הספרייה vue-i18n משתמשת בתחביר ריבוי משלה המופרד בתווי pipe (|), ולא ב-ICU. עובדה זו קריטית אם המחרוזות מגיעות מגורם חיצוני.
3. כמה שפות ועמודים יש באפליקציה? שתי שפות וחמישה עמודים יכולים לטעון הכל מראש. עשר שפות וארבעים נתיבים לא יכולים, ואסטרטגיית הטעינה הופכת לעלות המרכזית.
4. האם אתם זקוקים לטיפוסים על מפתחות (Types on keys)? קריאה ל-t("cart.totl") תעבור קומפילציה ב-vue-i18n אלא אם תעבירו טיפוס גנרי של סכמת הודעות, וסכמה זו מתנגשת לעיתים קרובות עם קטלוגים בטעינה מושהית (lazy).
5. מה מכיל התוכן? תוויות ממשק בלבד, או מסמכי Markdown, קישורים בתוך משפטים ובלוקים מותאמים לכל שפה. תוכן עשיר הוא המקום שבו פונקציית t() המחזירה מחרוזת הופכת למסורבלת.
6. האם CSP מהווה אילוץ? גרסת הבנייה המוגדרת כברירת מחדל ב-vue-i18n מקמפלת הודעות בדפדפן באמצעות new Function. גרסאות זמן ריצה בלבד (Runtime-only) דורשות את @intlify/unplugin-vue-i18n לצורך קומפילציה מקדימה בזמן בנייה.

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

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

באקוסיסטם של Vue יש פחות ספריות i18n מאשר ב-React, והן מגיעות מגלים ארכיטקטוניים שונים.

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

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

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

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

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

הספרייה vue-i18n תומכת בציר הדינמי: שימוש ב-setLocaleMessage לאחר קריאת import() מאפשר להפסיק לשלוח תשע שפות שאיש אינו קורא. מה שהיא אינה מספקת הוא את ציר העמודים. קטלוג שפה הוא אובייקט יחיד, וטעינתו טוענת את הטקסט של כל העמודים באפליקציה. באפליקציית SPA איש אינו מבחין בכך. ב-Nuxt, עם @nuxtjs/i18n ומעל לעשרה עמודים, כל נתיב נושא את המחרוזות של כל שאר הנתיבים פעמיים: בתוך מקטע ה-JS ובתוך ה-payload של ה-SSR.

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

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

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

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

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

פעילות Commits

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

הורדות ב-npm

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

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

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

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

• vue-i18n: הכבדה ביותר בקבוצה, פורמט ריבוי עצמאי, טיפוסים מוגדרים ידנית ושבירים בעת טעינה מושהית, ללא תיחום לפי נתיב, ומפתחות מתים מצטברים בשקט. השארת legacy: true באפליקציית Vue 3 משאירה את שכבת התאימות של Vue 2 ומבטלת את הטיפוסיות של useI18n().
• @nuxtjs/i18n: יורשת את כל המגבלות שלעיל, ובנוסף ה-payload של ה-SSR נושא את המחרוזות של כל עמוד ברגע שעוברים תריסר נתיבים.
• fluent-vue: תחביר הודעות אלגנטי, ללא טיפוסים על מפתחות, ותוסף ה-Vite טוען את כל התוכן בכל השפות לתוך כל עמוד. הכבדה ביותר במבחן הביצועים.
• Paraglide: קבצים הנוצרים ישירות בתוך המאגר, יצירה מחדש לפני כל push, והשפה נקראת מעוגייה או אחסון בכל קריאת הודעה במקום מתוך reactive store, מה שגורר פעולות מיותרות בהחלפת שפה.
• Intlayer: מחייבת תוסף בנייה, אקוסיסטם קטן יותר, תמיכת ICU חלקית, ותוכן המפוזר בבסיס הקוד מעצם התכנון, כך שייצוא JSON בודד למתרגם דורש שימוש בכלי עזר.

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

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

{
  "cart": {
    "title": "Your cart",
    "items": "no item | one item | {count} items"
  }
}

{
  "cart": {
    "title": "Votre panier",
    "items": "aucun article | un article | {count} articles"
  }
}

{
  "cart": {
    "title": "Tu carrito",
    "items": "ningún artículo | un artículo | {count} artículos"
  }
}

<script setup lang="ts">
import { useI18n } from "vue-i18n";

const props = defineProps<{ count: number }>();
const { t } = useI18n();
</script>

<template>
  <section>
    <h2>{{ t("cart.title") }}</h2>
    <p>{{ t("cart.items", { count: props.count }, props.count) }}</p>
  </section>
</template>

cart-title = Your cart
cart-items = { $count ->
    [one] { $count } item
   *[other] { $count } items
}

cart-title = Votre panier
cart-items = { $count ->
    [one] { $count } article
   *[other] { $count } articles
}

cart-title = Tu carrito
cart-items = { $count ->
    [one] { $count } artículo
   *[other] { $count } artículos
}

<script setup lang="ts">
import { useFluent } from "fluent-vue";

const props = defineProps<{ count: number }>();
const { $t } = useFluent();
</script>

<template>
  <section>
    <h2>{{ $t("cart-title") }}</h2>
    <p>{{ $t("cart-items", { count: props.count }) }}</p>
  </section>
</template>

{
  "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 setup lang="ts">
import { m } from "../paraglide/messages.js";

const props = defineProps<{ count: number }>();
</script>

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

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 setup lang="ts">
import { useIntlayer } from "vue-intlayer";

const props = defineProps<{ count: number }>();
const { title, items } = useIntlayer("cart-summary");
</script>

<template>
  <section>
    <h2><title /></h2>
    <p>{{ items(props.count) }}</p>
  </section>
</template>

כבר משתמשים ב-vue-i18n? מתאם התאימות של @intlayer/vue-i18n מספק כינוי (alias) לחבילה ברמת ה-bundler, כך ש-useI18n(), $t, ריבוי מבוסס pipe וההוראה v-t ממשיכים לפעול בזמן ש-Intlayer מגישה את התוכן. מדריך ההגירה מכסה את שלבי המעבר מהמתאם לאחר מכן, וקיים גם מדריך ייעודי ל-Nuxt.

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

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

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

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

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

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

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

הספרייה vue-i18n נתמכת על ידי Crowdin, בדומה ל-next-intl ו-svelte-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.

שאלות נפוצות

קריאה נוספת

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