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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

React:

לפני

<button>Submit</button>

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

<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“. כשיש ספק, בחרו במילה הקצרה והנפוצה יותר.

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

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

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

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

צרו פרויקט ב־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 דקות.

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