שיטות מומלצות ללוקליזציה של תוכנה: 10 שלבים עם דוגמאות

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

האפליקציה שלכם הושקה זה עתה בצרפת. ההרשמות מתחילות לזרום, ואז תיבת הדואר הנכנס של התמיכה מתחילה להתמלא בקריאות שירות. משתמשים לא יכולים ללחוץ על כפתור ה־“Buy now” כי הוא נחתך. תפריטי הניווט נשברים לשתי שורות. ממשק המשתמש שהשקעתם בעיצובו נראה שבור לחלוטין.

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

מדריך זה מכסה את כל מה שצריך כדי לבצע לוקליזציה של תוכנה בצורה נכונה. תלמדו:

• מהי לוקליזציה של תוכנה
• ההבדל בין לוקליזציה, תרגום ובינאום (Internationalization)
• איך להתכונן לתהליך לוקליזציה של תוכנה
• שיטות מומלצות לתוכן דינמי, התרחבות טקסט, עיצוב מותאם אזור ובדיקות
• העלות של לוקליזציה לתוכנה
• איך להגדיר תזרים עבודה של לוקליזציה שלא נשבר בכל גרסה

מהי לוקליזציה של תוכנה?

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

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

הנה דוגמה שמראה איך אותו תאריך יכול לקבל שתי משמעויות שונות בהתאם למיקום המשתמש:

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

לוקליזציה של תוכנה לעומת תרגום לעומת בינאום

אנשים רבים משתמשים בשלושת המונחים הללו כאילו היו מילים נרדפות, אך הם בעלי משמעויות שונות ומתרחשים בשלבים שונים של הפיתוח.

תהליך הלוקליזציה של תוכנה

לוקליזציה של תוכנה אינה שלב בודד שמסיימים לפני ההשקה. זהו תהליך מתמשך שרץ לצד הפיתוח. הנה סקירה של האופן שבו הוא מתחלק בדרך כלל:

רוב הצוותים מנהלים את התהליך באחת משלוש דרכים:

1. Waterfall (מודל מפל המים): הלוקליזציה מתחילה לאחר סיום הפיתוח. מסיימים לבנות, ואז מעבירים הכל לתרגום במקבץ אחד. זה פשוט לניהול, אך זה מעכב את ההשקה בשפות אחרות והופך את תיקון הבאגים ליקר בשלב זה.
2. לוקליזציה אג'ילית (Agile): הלוקליזציה רצה לצד הפיתוח. במקום מקבץ גדול אחד בסוף, שולחים מחרוזות לתרגום לאורך כל מחזור הפיתוח. התזמון טוב יותר, אך התהליך עדיין ידני. מישהו מהצוות צריך לייצא מחרוזות, לנהל את ההעברות ולייבא את התרגומים בחזרה.
3. תרגום רציף (Continuous localization): הלוקליזציה אוטומטית לחלוטין. המאגר שלכם מתחבר ישירות לכלי התרגום, כך שכשמחרוזת משתנה, היא נשלחת לתרגום אוטומטית. כשהתרגום מוכן, הוא ממוזג בחזרה באופן אוטומטי.

שיטות מומלצות ללוקליזציה של תוכנה

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

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

כשאתם כותבים טקסט ישירות בתוך קוד המקור (Hard-coding), כלי תרגום לא יכולים למצוא אותו. כלים אלו עובדים על ידי סריקת קובצי משאבים כמו JSON, PO או YAML בחיפוש אחר מחרוזות לתרגום. אם הטקסט שלכם קבור בתוך קובצי JavaScript, PHP או Ruby, הסריקה תחזור ריקה.

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

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

• תוויות ממשק משתמש, כפתורים ופריטי תפריט
• הודעות שגיאה וטקסט אימות (Validation)
• תבניות אימייל והתראות
• טקסט עזרה, Tooltips וטקסט של מצייני מיקום
• הודעות הצלחה ואישור

פורמט הקובץ שבו תשתמשו תלוי בפריימוורק שלכם:

הנה דוגמה של "לפני ואחרי" עבור כל פריימוורק מרכזי.

React:

לפני

<button>Submit</button>

אחרי, שימוש ב־react-i18next

<button>{t('submit_button')}</button>

WordPress:

לפני

echo 'Submit';

אחרי, WordPress i18n

echo __( 'Submit', 'your-textdomain' );

Ruby on Rails:

לפני

flash[:notice] = "Profile updated successfully"

אחרי, שימוש ב־Rails I18n:

flash[:notice] = t('profile.update_success')

חשוב גם לתת למחרוזות שלכם מפתחות (Keys) ברורים ותיאוריים. מפתח בשם checkout.submit_button אומר למתרגם בדיוק איפה המחרוזת הזו מופיעה ומה היא עושה. מצד שני, string_147 לא אומר להם כלום, מה שמוביל לטעויות בתרגום. מפתחות תיאוריים גם מקלים על הצוות שלכם לעקוב אחר המחרוזות שהוצאו לקבצים חיצוניים ולזהות אם משהו חסר.

השתמשו במצייני מיקום עבור שמות, מספרים ותאריכים

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

הנה הסיבה:

const message = 'Hello, ' + name + '!';

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

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

כך נראים מצייני מיקום בפורמטים שונים של קבצים:

JSON:

{ "greeting": "Hello, {name}!" }

YAML:

greeting: "Hello, %{name}!"

PO:

msgid "Hello, %s!"

התחביר משתנה לפי הפורמט, אך העיקרון זהה.

בנו את ממשק המשתמש כך שיתמודד עם טקסט ארוך יותר

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

אלו שיעורי ההתרחבות הטיפוסיים שתעבדו איתם:

מילים בודדות יכולות להתרחב הרבה מעבר לממוצעים הללו. “FAQ” הופך ל־“Preguntas frecuentes” בספרדית — זוהי עלייה של 567%.

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

לפני — רוחב קבוע שנשבר בשפות ארוכות יותר

button { width: 120px; }

אחרי — גדל יחד עם הטקסט המתורגם

button {
  min-width: 120px;
  width: auto;
  padding: 8px 16px;
}

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

כתבו טקסט שקל לתרגם

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

הבעיות הנפוצות ביותר שיש להימנע מהן:

משפטים חסרים

מחרוזת כמו “No items” יכולה להביע כמה דברים. האם אין פריטים בעגלה? האם חיפוש לא החזיר תוצאות? המתרגם שלכם צריך לנחש, וניחוש שגוי פירושו תרגום שגוי.

כתבו משפטים מלאים עם נושא ופועל ברורים.

לפני — מעורפל

"No items"

אחרי — משמעות ברורה

"You have no items in your cart."

ביטויים וניבים

“This is a piece of cake” מובן לדובר אנגלית כשפת אם. בתרגום מילולי לגרמנית, המשתמשים שלכם יתהו למה האפליקציה מדברת על קינוחים. רוב הביטויים עובדים רק בשפה נתונה, לכן עדיף להימנע מהם לחלוטין.

אוצר מילים מורכב

מילים פשוטות מיתרגמות בצורה אמינה יותר. כתבו “remove” במקום “eliminate” ו־“use” במקום “utilize”. כשיש ספק, בחרו במילה הקצרה והנפוצה יותר.

נהלו תאריכים, מספרים ומטבעות בצורה נכונה

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

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

JavaScript:

לפני

const price = '$' + amount.toFixed(2);

אחרי

const price = new Intl.NumberFormat(userLocale, {
  style: 'currency',
  currency: currencyCode
}).format(amount);

Ruby on Rails:

לפני

"$#{price}"

אחרי

number_to_currency(price, locale: I18n.locale)

בדרך זו, אותו קוד מנהל את העיצוב בצורה נכונה עבור כל אזור שבו אתם תומכים.

תכננו עבור אזור (Locale), לא רק עבור שפה

שפה ואזור אינם אותו דבר. ספרדית היא שפה. ספרדית מקסיקנית (es-MX), ספרדית מספרד (es-ES) וספרדית ארגנטינאית (es-AR) הם אזורים. ההבדלים ביניהם חורגים מעבר לאוצר מילים. פורמטים של תאריכים, מטבע, הקשרים תרבותיים וטון הדיבור יכולים להשתנות.

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

קחו את הצרפתית כדוגמה:

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

תנו למתרגמים את ההקשר שהם צריכים

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

מחרוזת כמו “Cancel” יכולה להתייחס לביטול הזמנה, ביטול מנוי או ביטול שליחת טופס. כל אחד מאלה עשוי להיתרגם אחרת בהתאם לשפה.

הוסיפו הערות לקובצי המשאבים שלכם כדי להסביר מה כל מחרוזת עושה ואיפה היא מופיעה:

JSON עם הערות הקשר

{
  // Button in the checkout flow. Cancels the current order. Keep short.
  "checkout.cancel_button": "Cancel",

  // Error message shown when login fails. Followed by a link to reset password.
  "auth.login_error": "Incorrect email or password."
}

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

הגדירו זיהוי שפה

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

React עם react-i18next:

i18n
  .use(LanguageDetector)
  .use(initReactI18next)
  .init({
    resources,
    fallbackLng: 'en',
    detection: {
      order: ['navigator', 'localStorage']
    }
  });

Ruby on Rails:

before_action :set_locale

def set_locale
  I18n.locale = extract_locale_from_accept_language_header || I18n.default_locale
end

תמיד הגדירו שפת גיבוי (Fallback). כשקובץ תרגום חסר או כשמחרוזת עדיין לא תורגמה, האפליקציה שלכם תציג את הגיבוי במקום מפתח שבור כמו auth.login_error.

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

// Save the user's choice
localStorage.setItem('userLanguage', selectedLanguage);

// Check for a saved choice first, then fall back to the browser language
const userLanguage = localStorage.getItem('userLanguage') || navigator.language;

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

בחרו כלי לוקליזציה

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

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

• יתחבר למאגר שלכם, יזהה מחרוזות חדשות ומשתנות, וישמור על התרגומים מעודכנים באופן רציף
• ייתן לצוות שלכם מקום מרכזי לניהול כל התרגומים
• יכלול תכונות CAT מובנות כמו זיכרון תרגומי, זיהוי מגבלות אורך וניהול מילון מונחים

PTC עושה את כל זה. בנוסף, תוכלו לתרגם את 20,000 המילים הראשונות ל־2 שפות בחינם, וההתחלה לוקחת פחות מ־5 דקות.

למדו איך PTC מנהל לוקליזציה של תוכנה

בדקו כל גרסה מקומית לפני ההשקה

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

פריסה: האם הטקסט נכנס במלאו מבלי להיחתך? האם הניווט עדיין עובד, או שאתם רואים גלישה (Overflow)?

פונקציונליות: האם טפסים נשלחים בצורה נכונה? האם הודעות שגיאה מופיעות בשפה הנכונה? האם החיפוש מטפל בתווים עם סימני ניקוד כמו é, ñ ו־ü?

עיצוב פורמטים: האם התאריכים בפורמט הנכון לאזור? האם מספרים ומטבעות מעוצבים נכון? האם סמל המטבע נמצא במיקום הנכון?

שפות מימין לשמאל (RTL): אם אתם תומכים בערבית או בעברית, בדקו את כל פריסת ה־RTL בנפרד. תמיכה ב־RTL משפיעה על יותר מאשר רק כיוון הטקסט. היא משפיעה על כל פריסת ממשק המשתמש שלכם.

בנו בדיקות לוקליזציה בתוך תהליך ה־QA שלכם מההתחלה. גילוי של תהליך תשלום (Checkout) שבור בגרמנית דרך ביקורות משתמשים הוא יקר משמעותית מאשר תפיסתו לפני ההשקה.

כמה עולה לוקליזציה של תוכנה?

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

תרגום אנושי מקצועי לתוכנה עולה בדרך כלל בין $0.10 ל־$0.30 למילה. עבור אפליקציה בגודל בינוני עם 15,000 מילים, מדובר ב־$1,500 עד $4,500 לכל שפה, לפני שמשקללים בדיקות, ניהול פרויקט או עדכונים עתידיים בכל פעם שהמוצר שלכם משתנה.

תרגום בבינה מלאכותית עם כלי כמו PTC עולה שבריר מזה:

לאחר תקופת הניסיון בחינם, PTC עובד במודל Pay-As-You-Go. 500 המילים הראשונות שלכם בכל חודש הן בחינם. ככל שתתרגמו יותר, המחיר למילה ירד, וברגע שתגיעו לתעריף נמוך יותר, תשמרו עליו למשך שלושה חודשים גם אם נפח התרגום שלכם ירד.

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

חשבו את עלות התרגום שלכם

הגדירו את תהליך הלוקליזציה שלכם ב־3 שלבים

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

הרשמה ל־PTC

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

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

כל ההגדרה לוקחת פחות מ־5 דקות.

צפייה ושיפור של תרגומים

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

AI Visual QA לוקח את תהליך הסקירה הסטנדרטי ברמת המחרוזת צעד אחד קדימה על ידי בחינת ממשק המשתמש האמיתי שלכם בכל שפות היעד.

היפרדו מ:

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

מה תקבלו במקום זאת:

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

כדי להתחיל, עברו ללשונית AI Visual QA מלוח הבקרה שלכם. בהתאם לסוג התוכנה שאתם מתרגמים, תוכלו להעלות צילומי מסך של ממשק המשתמש שלכם או להשתמש ב־תוסף הדפדפן PTC Visual QA כדי להקליט את המסכים לסקירה.

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

חברו את תזרים עבודת הפיתוח שלכם

כשנוח לכם עם אופן העבודה של PTC, שדרגו ל־Pay-As-You-Go כדי לקבל גישה לתכונות Pro, כמו חיבור PTC למאגר ה־GitHub, ה־GitLab או ה־Bitbucket שלכם. עם אינטגרציה זו, PTC מזהה מחרוזות חדשות ומשתנות באופן אוטומטי ושומר על התרגומים שלכם מעודכנים ללא העלאת קבצים ידנית.

אם תרצו להתקדם עוד יותר, ה־API של PTC מאפשר לכם לשלב תרגום ישירות בתוך צינור ה־CI/CD שלכם, כך שגרסאות מקומיות תמיד מוכנות להפצה לצד שפת המקור שלכם.

התחילו להשתמש ב־PTC בחינם למשך 30 יום

דוגמה ללוקליזציה של תוכנה: תרגום WPML באמצעות PTC

WPML הוא אחד התוספים הרב־לשוניים הנפוצים ביותר עבור WordPress. שמירה על התרגום שלו ב־23 שפות אינה בגדר רשות. זהו חלק מכל הפצה.

במשך שנים, הצוות עשה זאת בדרך המסורתית: שכירת מתרגמים אנושיים מקצועיים, ניהול קובצי מילון מונחים ותיאום עדכונים בכל השפות עבור כל גרסה. בכל פעם, הם היו צריכים להסביר מחדש את המוצר, את הטרמינולוגיה ואת הציפיות מאפס. העלות נעה בין $1,000 ל־$8,000 לכל הפצה.

הם ניסו חלופות: מיקור המונים (Crowdsourcing), תזרימי עבודה אוטומטיים ומודלים היברידיים. שום דבר לא פתר את הבעיה.

מאז המעבר ל־PTC, הגרסאות יוצאות בזמן. התרגומים מלאים, מדויקים ועקביים בכל 23 השפות, ללא הקפאת מחרוזות (String freeze), ללא עומס תיאום וללא עיכובים.

לפני PTC

אחרי PTC

התחילו לבצע לוקליזציה לתוכנה שלכם היום

PTC בחינם עבור 20,000 המילים הראשונות שלכם ב־2 שפות. ההתחלה לוקחת פחות מ־5 דקות.

התחילו את תקופת הניסיון בחינם