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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

React:

לפני

<button>Submit</button>

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

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

WordPress:

לפני

echo 'Submit';

אחרי, i18n של WordPress

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

Ruby on Rails:

לפני

flash[:notice] = "Profile updated successfully"

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

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

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

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

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

השתמשו בכלי הלוקליזציה המובנים של ה־framework שלכם כדי לעצב אותם באופן אוטומטי על סמך ה־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 שאתם תומכים בו.

תכננו עבור locale, לא רק עבור שפה

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

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

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

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

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

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

מחרוזת כמו "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."
}

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

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

לאחר שהמחרוזות שלכם נמצאות בקובצי משאבים וממשק המשתמש שלכם גמיש, עליכם להציג לכל משתמש את השפה הנכונה באופן אוטומטי. רוב ה־frameworks מטפלים בכך בעזרת ספריות 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

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

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

// 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 מחרוזות, ומתחילים מחדש. זה לא עובד בקנה מידה גדול.

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

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

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

למדו כיצד PTC מטפלת בלוקליזציה של תוכנה

בדקו כל גרסה שעברה לוקליזציה לפני ההשקה

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

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

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

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

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

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

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

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

תרגום אנושי מקצועי עבור תוכנה עולה בדרך כלל בין $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 תסרוק אחר בעיות שמופיעות רק כשהאפליקציה שלכם רצה. היא מתקנת אוטומטית בעיות ברמת התרגום, כמו ניסוח מסורבל, טון שגוי או טקסט שאינו מתאים להקשר. בעיות ברמת הקוד, כגון מפתחות חסרים, מחרוזות מוטמעות בקוד ובאגים בעיצוב, מסומנות כדי שהצוות שלכם יפתור אותן במקור.

חברו את תהליך הפיתוח שלכם

כאשר תרגישו בנוח עם האופן שבו 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 השפות, ללא הקפאת מחרוזות, ללא תקורה של תיאום וללא עיכובים.

לפני PTC

אחרי PTC

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

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

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